Gradle 2.0-rc-1 is now available for testing


(Radim Kubacki) #1

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


(Jörn Huxhorn) #2

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.)


(gilbode) #3

Hmm,

  • What went wrong: A problem occurred evaluating script. > Could not find property ‘Compile’ on root project ‘buildSrc’.

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?


(Radim Kubacki) #4

To mikeg922: Compile was deprecated previously and is now replaced by JavaCompile. It is also documented in release notes.


(Jörn Huxhorn) #5

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.


(gilbode) #6

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?


#7

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]

in https://github.com/spring-projects/gradle-plugins/blob/master/propdeps-plugin/src/main/groovy/org/springframework/build/gradle/propdep/PropDepsIdeaPlugin.groovy.


(Peter Niederwieser) #8

btw this is https://jira.codehaus.org/browse/GROOVY-6018


(Jörn Huxhorn) #9

I created an issue for this: https://github.com/spring-projects/gradle-plugins/issues/41


(Jochen Berger) #10

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.


(Luke Daley) #11

@Jochen,

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?


(Jochen Berger) #12

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.


(Jörn Huxhorn) #13

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.


#14

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.


(Jochen Berger) #15

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.


(Jochen Berger) #16

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


(Luke Daley) #17

This doesn’t work for me in Gradle 1.10, 1.11 or 1.12.


(Jochen Berger) #18

I haven’t tested 1.10 or 1.11. The real issue for me is that neither method works with the 2.0 RCs.


(Luke Daley) #19

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.


(Jochen Berger) #20

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.