Gradle 1.6-rc-1 is now available for testing

Old Forum Archive
1

The Gradle team is pleased to announce that the release candidate for Gradle 1.6 is now available.

Task ordering rules offer you more control over the execution of tasks, there’s now a JaCoCo plugin for test coverage, and the Junit integration supports test categories.

To help get you started with Gradle, this release introduces the build setup plugin. This plugin takes care of the work of setting up a new build. This includes support for converting an Apache Maven POM to a Gradle build. You simply point Gradle at your current Maven build and you end up with a functioning Gradle build. Note that this plugin is in early stages of development and we plan to improve it in future releases.

Continuing on the performance work of the last few releases, Gradle 1.6 will include support for incremental tasks. These are tasks that selectively process only those inputs that have changed, and avoid processing those inputs that have not changed. For detailed information about Gradle 1.6, please see gradle.org/release-candidate.

Please try this release candidate with your projects and let us know if you encounter any issues.

2

I get lots of messages like this:

Checksum missing at http://repo1.maven.org/maven2/org/ow2/asm/asm-commons/4.0/asm-commons-4.0.pom.sha1 due to: Could not GET 'http://repo1.maven.org/maven2/org/ow2/asm/asm-commons/4.0/asm-commons-4.0.pom.sha1'.

The problem is: the file does actually exist.

My very first build even failed (see http://pastebin.com/CA2HtCg5 )

See the following links for some more examples of output created by building sulky and lilith:

Beside that, I get the following output:

The TaskContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead.
The groovy configuration has been deprecated and is scheduled to be removed in Gradle 2.0. Typically, usages of 'groovy' can simply be replaced with 'compile'. In some cases, it may be necessary to additionally configure the 'groovyClasspath' property of GroovyCompile and Groovydoc tasks.

One problem is that there is no corresponding link about what exactly causes the problems and how to fix them. I’m not sure that deprecating the groovy configuration is a good idea. Replacing it with compile isn’t really comparable, in my opinion. It’s more like defining the Java version to be used.

I usually just apply the “groovy” plugin for all subprojects so I’m able to use spock as the testing framework. I then configure some global dependencies in subprojects:

dependencies {
  groovy libraries.'groovy'
      testCompile libraries.'groovy'
  testCompile libraries.'spock-core'
  testCompile libraries.junit
  testCompile libraries.'slf4j-api'
  testRuntime libraries.'logback-classic'
 }

But this does not mean that all my modules require groovy as a compile dependency. Should I just remove the groovy entry in the above example?

Everything else seems to work fine.

3

Regarding the “checksum missing” error, this sounds like a network problem. In any case, can you try a clean build that also uses ‘–refresh-dependencies’?

Regarding deprecation of ‘TaskContainer.add’, do you use ‘tasks.add’ somewhere (build script, custom plugin)? In that case, you’ll need to change it to ‘tasks.create’. Note that the usage may also come from a third-party plugin.

Regarding deprecation of the ‘groovy’ configuration, your current setup is redundant. If you add a dependency to ‘groovy’, it’s also on ‘testCompile’ (and also on ‘compile’). So yes, just remove the ‘groovy’ entry. This will be a change to the better, as you won’t pollute ‘compile’ anymore.

4

Running a clean and then doing a build with ‘–refresh-dependencies’ did not reproduce the errors.

But cleaning ~/.gradle, i.e. removing anything that I didn’t put there manually, did the job of reproducing it.

I doubt that this is a network problem since only .sha1 files produce any problems at all while downloading the other files works flawlessly.

Checksum missing at http://repo1.maven.org/maven2/org/ow2/asm/asm-analysis/4.0/asm-analysis-4.0.jar.sha1 due to: Could not GET 'http://repo1.maven.org/maven2/org/ow2/asm/asm-analysis/4.0/asm-analysis-4.0.jar.sha1'.

You can try it yourself. Just clone https://github.com/huxi/sulky - I use gradlew.

Thanks for the info about the other warnings. Will have a look tomorrow.

5

Is this an error that stops the build? I can’t reproduce it.

6

I experienced the “Checksum missing” problem with 1.5 yesterday using a direct connection to the Internet. Happened once or twice then stopped. I’m not able to reproduce.

7

The build failure in the first pastebin happened to me only during the first build. Couldn’t reproduce it either.

But the messages about failed sha1 downloads keep repeating after deleting the stuff in ‘~/.gradle’.

Another issue I found while doing that is that ‘gradle --stop’ does not stop all running gradle daemons.

  huxi@~/Documents/Projects/huxi/sulky (master) > ps | grep java  62397 ttys001

 1:11.01 /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -cp /Users/huxi/.gradle/wrapper/dists/gradle-1.6-rc-1-bin/7rfpo90hvklfllkcb1p7g14ma1/gradle-1.6-rc-1/lib/gradle-launcher-1.6-rc-1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 1.6-rc-1 /Users/huxi/.gradle/daemon 10800000 be492c60-dbcd-40c8-a65d-3b771dd8e696 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8  63353 ttys001

 0:44.61 /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -cp /Users/huxi/.gradle/wrapper/dists/gradle-1.6-rc-1-bin/7rfpo90hvklfllkcb1p7g14ma1/gradle-1.6-rc-1/lib/gradle-launcher-1.6-rc-1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 1.6-rc-1 /Users/huxi/.gradle/daemon 10800000 8e0fb957-6f8e-48ff-af16-5f74cef3cbb0 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8  63468 ttys001

 0:00.00 grep java  huxi@~/Documents/Projects/huxi/sulky (master) > gradlew --stop  Stopping daemon(s).  Gradle daemon stopped.  huxi@~/Documents/Projects/huxi/sulky (master) > ps | grep java  62397 ttys001

 1:11.05 /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -cp /Users/huxi/.gradle/wrapper/dists/gradle-1.6-rc-1-bin/7rfpo90hvklfllkcb1p7g14ma1/gradle-1.6-rc-1/lib/gradle-launcher-1.6-rc-1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 1.6-rc-1 /Users/huxi/.gradle/daemon 10800000 be492c60-dbcd-40c8-a65d-3b771dd8e696 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8  63493 ttys001

 0:00.00 grep java  huxi@~/Documents/Projects/huxi/sulky (master) > gradlew --stop  No Gradle daemons are running.  huxi@~/Documents/Projects/huxi/sulky (master) > ps | grep java  62397 ttys001

 1:11.05 /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -cp /Users/huxi/.gradle/wrapper/dists/gradle-1.6-rc-1-bin/7rfpo90hvklfllkcb1p7g14ma1/gradle-1.6-rc-1/lib/gradle-launcher-1.6-rc-1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 1.6-rc-1 /Users/huxi/.gradle/daemon 10800000 be492c60-dbcd-40c8-a65d-3b771dd8e696 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8  63517 ttys001

 0:00.00 grep java

I need to kill it manually to get rid of locked files in ‘~/.gradle’.

8

But the messages about failed sha1 downloads keep repeating after deleting the stuff in ~/.gradle.

Tried this as well, but still couldn’t reproduce. Again, does this fail the build, or is it just a log message? Did you crank up the logging level to info or debug to see this message?

9

Hi Peter, I’m using project.tasks.add( taskName, taskClass ) in my plugins. If this call is replaced to project.tasks.create( taskName, taskClass ) - it will fail on Gradle prior to 1.6 so does it mean we should use reflection to find out which Gradle version is available at run-time to make a proper call?

10

Ideally, deprecation warnings would only be shown for build script usages, but not for plugin usages. However, there is currently no such differentiation. This means that you can either choose the “correct” method based on the Gradle version (‘gradle.gradleVersion’), or live with the deprecation warning (which will sadly effect your users).

11

Ok, I don’t mind choosing the right method at run time, will do that. Thanks!

12

I got 1 checksum error on my plugin build and then these 3 from the first project task execution

Checksum missing at http://repo1.maven.org/maven2/com/eriwen/gradle-css-plugin/1.2.1/gradle-css-plugin-1.2.1.pom.sha1 due to: Could not GET 'http://repo1.maven.org/maven2/com/eriwen/gradle-css-plugin/1.2.1/gradle-css-plugin-1.2.1.pom.sha1'.
Download http://repo1.maven.org/maven2/com/eriwen/gradle-css-plugin/1.2.1/gradle-css-plugin-1.2.1.pom
Checksum missing at http://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v20130227/closure-compiler-v20130227.pom.sha1 due to: Could not GET 'http://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v20130227/closure-compiler-v20130227.pom.sha1'.
Download http://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v20130227/closure-compiler-v20130227.pom
Checksum missing at http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.8.2/ant-launcher-1.8.2.pom.sha1 due to: Could not GET 'http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.8.2/ant-launcher-1.8.2.pom.sha1'.
Download http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.8.2/ant-launcher-1.8.2.pom

But subsequent builds were fine no refresh or any cleanup required (going from 1.5 to 1.6-rc-1)

13

When using the build setup plugin, is there any way to configure repositories other than central?

14

I tried this (setupBuild) today on my project and it failed right away with a stack overflow.

Stuck in the following infinite loop:

19:32:53.157 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.generateFqn(Maven2Gradle.groovy:253) 19:32:53.162 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.this$2$generateFqn(Maven2Gradle.groovy) 19:32:53.168 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle$this$2$generateFqn.callCurrent(Unknown Source) 19:32:53.175 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.generateFqn(Maven2Gradle.groovy:253) 19:32:53.181 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.this$2$generateFqn(Maven2Gradle.groovy) 19:32:53.188 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle$this$2$generateFqn.callCurrent(Unknown Source) 19:32:53.193 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.generateFqn(Maven2Gradle.groovy:253) 19:32:53.198 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle.this$2$generateFqn(Maven2Gradle.groovy) 19:32:53.202 [ERROR] [org.gradle.BuildExceptionReporter]

at org.gradle.buildsetup.plugins.internal.maven.Maven2Gradle$this$2$generateFqn.callCurrent(Unknown Source)

15

@kellyrob. The maven2gradle task reuses the repository definition of your effective Pom. If no repo is defined, it defaults to mavencentral

16

@swpalmer thanks for reporting this. I have to dig a bit into the code to check where this somes from. Can you provide some information about the maven project you’re trying to convert. E.g which plugins do you use? Single module/multimodule?

17

This is a multi-module project with 11 modules. Ar first I thought it might be because two of the projects already have a build.gradle file (part of the Maven build on those modules runs gradle via the exec plugin) so I moved the build.gradle file aside to see if that made a difference and it did not.

The root project uses one plugin to assist with Eclipse integration 

  <plugin>

<groupId>org.eclipse.m2e</groupId>


<artifactId>lifecycle-mapping</artifactId>


<version>1.0.0</version>


…
The other modules use several plugins. The main module has the following uses of plugins mentioned in the pom: 
maven-compiler-plugin  (to set source level to 1.7)


maven-jar-plugin


build-helper-maven-plugin (add-source)


build-helper-maven-plugin (attach-artifact)


maven-antrun-plugin  (to run javah)


maven-dependency-plugin  (to unpack some dependencies in generate-sources phase - they have source code that is added to the build)


proguard-maven-plugin (for obfuscation)


maven-javadoc-plugin (to exclude certain packages)

Other modules are similar, but also use: 

maven-antrun-plugin  (to run schemagen)


maven-assembly-plugin


exec-maven-plugin  (to run visualstudio’s devenv or make depending on the platform)

I could probably refactor some of that to get rid of maven-antrun-plugin in favour of exec-maven-plugin and that sort of thing. But it is a complex project that would make much more sense in 100% gradle… Specially if the development environments (Netbeans + Eclipse) expand their Gradle support. We only went with Maven because it was “standard”, it made sharing the project between the devs that like Eclipse and the devs that like Netbeans easier, and we needed dependency management. Otherwise we might have gone with Ant+Ivy, but that’s all ancient history now. I’m in the process of converting it all to use Gradle which we already use for parts of the build because Maven and Ant just didn’t cut it.

I’m not sure what to expect from “setupBuild” on this project… I doubted it would work 100%, but was hoping it would rough out a starting point for me to tweak. The stack overflow obviously shouldn’t happen given a valid Maven project though.

18

Thanks for the detailed report.I created a seperate thread to track this issue and have further discussions Please reference the new topic here: Maven2Gradle fails with Stack Overflow when generating full qualified name

19

Sorry, missed your comment.

I just tried to reproduce this on our company network (in contrast to my measly DSL16 at home) and wasn’t able to reproduce the problem anymore. Will try it again at home.

Chances are that this was simply caused by some hiccups of mavencentral that have since been corrected.

Concerning my log files above: I just called gradlew without any changes to the logging level. The build failed only in the first unreproducible example and still worked, even with the warnings, in all other cases.