Gradle 3.1 RC1 is now available for testing

Gradle 3.1 RC1 is now available for testing

Multi-project builds are a powerful feature with one significant constraint: the projects have to be in the same directory hierarchy. This doesn’t help if you want to work on code across multiple repositories, for example if you’re trying to fix a bug in a third-party open-source library that one of your projects depends on.

Gradle 3.1 now supports this scenario with the introduction of Composite Builds for all users. It’s hard to understate just how important this feature is as it provides a whole new way of organizing your projects and builds. There is more work to be done in this area and the feature is currently incubating, but we encourage you to try it out and give us your feedback!

Incremental Build is a similar feature in terms of impact and this release improves the control you have over its up-to-date checks. You can read about the details in the release notes.

As with many previous Gradle releases, you will also benefit from some performance improvements, this time in the form of faster dependency resolution. From testing, Android users specifically could see up to a 50% reduction in configuration and Android Studio sync time.

Our Play Framework and Kotlin build script users will also be happy as 3.1 now has (limited) support for Play 2.5.x and the Kotlin build script support gets a more fully-featured syntax for declaring dependencies and faster code completion.

Finally, be sure to check out the potential breaking changes in case they affect you.

Check the 3.1 RC1 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 3.1 RC1 quickly by updating your wrapper properties:

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

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

Reporting Problems

If you find a problem with Gradle 3.1 RC1, please post a reply to this topic or create a new topic in the Bugs category of the Gradle Forum. 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.

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

exactly how has dependency resolution been improved? has the resolution been parallelized (GRADLE-2582) ?

Everything fine with my usual projects.

1 Like

The issue below reared its head again. But it’s not a 3.1 regression, it never really went away. The stack trace for 3.1-rc-1 looks like this.

This time around it fails to find the class org.apache.maven.wagon.StreamWagon… it’s always the Maven Wagon dependency that is causing me problems like this. Unfortunately, this isn’t really reproducible and will probably be gone on our build server by tomorrow since we delete the Gradle cache in a Jenkins cron job.

The main problem is that it is happening rather randomly so people aren’t giving build failures on Jenkins the attention they deserve anymore since it could always be “one of those” failures.

Could you please open a JIRA issue for the classloader pollution problem mentioned by @sterling, or point me to one if it already exists.

@huxi Thanks again for letting us know about the re-occurrence of the issue. I created a JIRA issue and linked to it in your original post.

BTW: It would be great if we could get more information about the build when it is failing. Is there any chance your project can enable Build Scans via Gradle Cloud Services? A Build Scan would probably make it easier for us to see what’s going on under the covers.

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