The Gradle team is pleased to announce that the release candidate for Gradle 2.0 is now available.
Download links and release notes can be found as always at http://gradle.org/release-candidate.
Please try Gradle 2.0-rc-1 with your projects and let us know your experiences.
cheers,
Radim
Gradle 2.0-rc-1 fails to evaluate the build script of https://github.com/huxi/lilith
This is the output with --stacktrace: http://pastebin.com/YVtwPnVB
The error message indicates that the propdeps plugin is the reason for the failure. https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin
The annoying part about this is that the propdeps plugin is a workaround for the 4.5 year old http://issues.gradle.org/browse/GRADLE-784
(If you want to try this out yourself: You need to build https://github.com/huxi/sulky before Lilith. Otherwise the Lilith build won’t find necessary SNAPSHOT artifacts.)
Hmm,
Apparently it doesn’t like tasks.withType(Compile). In my build I can fully qualify the Compile task to bet past this but even trying to build gradle with this RC fails b/c it uses the same conventions. Is this really supposed to happen?
To mikeg922: Compile was deprecated previously and is now replaced by JavaCompile. It is also documented in release notes.
Any idea if the propdeps problem is a Gradle 2.0 bug or simply something that the propdeps developers would have to fix? I’m asking since I would file an issue there in case of the latter.
Oh right - seeing the same with Test which does still exist. Previously gradle API classes were usable without importing them explicitly. Has that changed in 2.0?
Looks like the propdeps plugin is hitting http://issues.gradle.org/browse/GRADLE-3101: this is due to a change in the way that groovy evaluates ‘+=’. The solution is to switch the idea plugin to replace:
scopes.PROVIDED.plus += project.configurations.provided
with
scopes.PROVIDED.plus += [project.configurations.provided]
There seems to be a change wrt. the classpath or class loading in task executions. I have a custom copy task in a subproject that uses a FilterReader to transform resources. The FilterReader is implemented in the buildSrc project. That one has a dependency on a library. One of the library’s searches for files on the classpath using its class loader. With Gradle 1.12 it finds the resource, with 2.0-rc-1 it doesn’t. So I /assume/, the problem is caused by some class loading-related change. If I should provide any more information, please let me know.
Can you provide some more detail please. A reproducible sample would be even better.
I don’t quite understand this sentence…
One of the library’s searches for files on the classpath using its class loader.
Is a class from a library declared in buildSrc/build.gradle loading a classpath resource using ‘getClass().getClassLoader().getResource()’ ? Where is the resource file that it’s trying to load located?
I didn’t go too much into detail because I’m completely unsure what might be relevant.
Is a class from a library declared in buildSrc/build.gradle loading a classpath resource using getClass().getClassLoader().getResource() ? Where is the resource file that it’s trying to load located?
Almost, the class is located in a library that’s a transitive dependency of the buildSrc. The task compiles CoffeeScript resources to JavaScript using a compiler library. The class I’m talking about is https://github.com/webjars/webjars-locator/blob/master/src/main/java/org/webjars/WebJarAssetLocator.java which the compiler library uses to find the compiler script. The script is located inside another jar which is also a dependency of the compiler library. I’ll try to create a reduced sample build soon.
Ok, I finally tested 2.0-rc-1 with the usual projects. A tentative thumbs-up.
The build server gets the following error: http://pastebin.com/AwF2j6Nk
This is the case if the following is applied:
project.allprojects { project ->
apply plugin: 'project-report'
apply plugin: 'groovy'
apply plugin: 'duplicates'
// http://evgeny-goldin.com/wiki/Gradle-duplicates-plugin
}
project.buildscript.dependencies {
classpath 'com.github.goldin.plugins.gradle:duplicates:0.3'
}
Removing the ‘duplicates’ plugin fixes that issue.
The really strange thing is that the above worked on my local system after I deleted the ‘.gradle’ directory of the project (not the one in ‘user.home’). I also had to perform a ‘gradle clean’ before the system was in a sane state, i.e. built without errors.
Sorry about this rather obscure description - but I thought I’d rather report something strange than nothing at all.
I’m guessing the ‘duplicates’ plugin has a dependency on ‘org.spockframework:spock-core:0.7-groovy-1.8’, which is incompatible with the version of Groovy that is now included in Gradle. The dependency report should give you a bit more information on what’s bringing in this dependency.
You might be able to work around this with a dependency resolve rule until the plugin has an update that is compatible with Gradle 2.0.
Just retried with rc-2, same issue. I’m still trying to come up with a small sample to reproduce the issue but it’s not so easy. However, I can even reproduce the problem with 1.12 if I create the compiler in the FilterReader’s constructor rather than using a ‘private final static’ instance. I guess, in that case, the compiler class (which triggers the loading of the the ‘WebJarAssetLocator’ class) is loaded at a later point at which the classpath is no longer the buildScript classpath. And in Gradle 2, that seems to be the default behavior.
Alright, here we go. https://gist.github.com/jochenberger/7fce9b533c75ebd3b973 You need to ‘mkdir src; touch src/foo’ first. If you run ‘gradle compileCoffeeScript --stacktrace’, you’ll see the problem (“coffee-script.min.js could not be found”). If you comment the ‘loadCoffeeScriptResource()’ in the c’tor and enable it in the ‘static’ block, no exception is thrown. Edit: this is with Gradle 1.12
This doesn’t work for me in Gradle 1.10, 1.11 or 1.12.
I haven’t tested 1.10 or 1.11. The real issue for me is that neither method works with the 2.0 RCs.
Your original post said this was a regression in 2.0. Your sample doesn’t work in earlier versions, so I can’t use it to track down the alleged regression in 2.0.
In the script I posted, if you comment the ‘loadCoffeeScriptResource()’ in the c’tor and enable it in the ‘static’ block, the ‘compileCoffeeScript’ task works with 1.12 but does not with 2.0.