Gradle 2.12-rc-1 is now available for testing

News Build Tool
1

Gradle 2.12-rc-1 is now available for testing

The Gradle team is pleased to bring you Gradle 2.12. This release brings support for compile only dependencies, improved build script compilation speed and even better IDE support.

Gradle 2.12 now finally includes support for modeling compile only dependencies when using the Java plugin. This capability establishes a much clearer migration path for those coming from Maven and have build requirements for which leveraging ‘provided’ scope was typically the solution.

We’ve introduced some improvements to test execution from the Gradle command line. Support has been added for executing specific test suites and parameterized tests making test-driven development using Gradle even easier.

With each Gradle release we strive to not only make the command line Gradle experience better but also using Gradle in conjunction with your favorite IDE even more enjoyable. Using Gradle with IntelliJ IDEA and the IDEA plugin now works better than ever. Manually managing Java target compatibility settings is no longer necessary as the IDEA plugin will now ensure that Gradle and the IDE consistently use the same compiler settings.

Additionally, our commitment to improving performance with each release continues. Gradle 2.12 has the fastest build script compilation speeds of any Gradle version to date.

Check the 2.12-rc-1 release notes for more information. If no regressions are reported, a final release will typically follow in the next week.

Upgrade Instructions

Switch your build to use Gradle 2.12-rc-1 quickly by updating your wrapper properties:

./gradlew wrapper --gradle-version=2.12-rc-1

Standalone downloads are available at https://gradle.org/release-candidate.

Reporting Problems

If you find a problem with Gradle 2.12-rc-1, please post a reply to this topic or create a new topic in Bugs. Be sure to include which operating system you are using, the version of Gradle you upgraded from and any steps you have found that reproduces your problem.

2

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

3

Everything fine with the usual three projects.
Except the stuff mentioned here but I didn’t expect it to be fixed since we couldn’t pinpoint the problem so far.

Regarding the new compileOnly:
Unlike provided with the propdeps-plugin, compileOnly is not written to the resulting Maven pom as a provided dependency. Not sure if this is intended…

Regarding the IDEA plugin:
We also have the following code in our Gradle files.

idea.module {
    iml.withXml {
        def attributes = it.asNode().component.content.sourceFolder
                .find { it.@url == 'file://$MODULE_DIR$/src/test/resources' }
        ?.attributes()
        if(attributes) {
            attributes.remove('isTestSource')
            attributes.put('type', 'java-test-resource')
        }
    }

    iml.withXml {
        def attributes = it.asNode().component.content.sourceFolder
                .find { it.@url == 'file://$MODULE_DIR$/src/main/resources' }
        ?.attributes()
        if(attributes) {
            attributes.remove('isTestSource')
            attributes.put('type', 'java-resource')
        }
    }

    inheritOutputDirs = false
    outputDir = file("$buildDir/classes/main/")
    testOutputDir =  file("$buildDir/classes/test/")
}

This ensures that main and test resources are registered properly in IDEA 15. It seems something has changed in the .iml IDEA files with IDEA 15. Without the above code, tests aren’t able to find resources addressed by getClass().getResourceAsStream() if executed in IDEA.

You might consider adding this or something similar if you are working on the idea plugin anyway.

4

For clarification on your third issue:

Are you reporting that this code is needed only when you use 2.12-rc-1 to generate your .iml files, or are you saying that this code is needed for IDEA 15 (independent of the version of gradle you are using to generate the .iml files?)

5

This is the intended behavior at this point. We might consider adding compileOnly dependencies to the Maven pom in future iterations. But right now, this is how it is supposed to work.

6

No, this was already the case with previous versions. I just wanted to mention it because you enhanced the idea-plugin.

7

The clojuresque plugin stops working with 2.12-rc-1:

...
Caused by: java.lang.NoSuchMethodError: org.gradle.api.internal.file.DefaultSourceDirectorySet.<init>(Ljava/lang/String;Lorg/gradle/api/internal/file/FileResolver;)V
    at clojuresque.tasks.ClojureSourceDirectorySet.<init>(ClojureSourceDirectorySet.groovy)
    at clojuresque.tasks.ClojureSourceSet.initSourceSet(ClojureSourceSet.groovy:32)
    at kotka.gradle.utils.tasks.GenericSourceSetConvention.<init>(GenericSourceSetConvention.groovy:57)
    at clojuresque.tasks.ClojureSourceSet.<init>(ClojureSourceSet.groovy)
    at clojuresque.ClojureBasePlugin$_configureSourceSets_closure2.doCall(ClojureBasePlugin.groovy:77)
    at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:67)
    at org.gradle.api.internal.DefaultDomainObjectCollection.all(DefaultDomainObjectCollection.java:110)
    at org.gradle.api.internal.DefaultDomainObjectCollection.all(DefaultDomainObjectCollection.java:115)
    at org.gradle.api.DomainObjectCollection$all$1.call(Unknown Source)
    at clojuresque.ClojureBasePlugin.configureSourceSets(ClojureBasePlugin.groovy:75)
    at clojuresque.ClojureBasePlugin.this$2$configureSourceSets(ClojureBasePlugin.groovy)
    at clojuresque.ClojureBasePlugin.apply(ClojureBasePlugin.groovy:55)
    at clojuresque.ClojureBasePlugin.apply(ClojureBasePlugin.groovy)
    at org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
    at org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:43)
    at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:137)
    at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:112)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:35)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:79)
    at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:135)
    at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
    at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
    at clojuresque.ClojurePlugin.apply(ClojurePlugin.groovy:31)
8

Thank you for reporting, @jochenberger. Looks like clojuresque is using an internal API that changed in this commit: https://github.com/gradle/gradle/commit/4e5e9fba8cb2456b191a1365d786e914b2526a7b. I’ll open an issue in clojuresque.

9

Issue for clojuresque opened at https://bitbucket.org/clojuresque/clojuresque/issues/4/plugin-stops-working-in-gradle-212.

10

This topic is no longer a banner. It will no longer appear at the top of every page.

11

please make compileOnly configuration available outside of the Java plugin

12

Unfortunately the clojuresque plugin is largely unmaintained so I’m stuck at Gradle 2.11 with many projects. Is there a chance that the old c’tor might be restored?