Gradle 3.4 RC1 is now available for testing

News Build Tool
1

Gradle 3.4 RC1 is now available

We’re excited to bring you 3 incredible performance features in this release.

First up: Compile Avoidance. We’ve introduced a new mechanism for up-to-date checking of Java compilation that is sensitive to public API changes only. This means that if you change a comment or even a private API in a downstream project, Java compilation for upstream projects will be UP-TO-DATE.

Next: A stable incremental Java compiler. We’ve smartened the handling of constants, backed it with in-memory caches, and fixed many bugs. It is now production-ready for your build and has been promoted out of @Incubating.

Finally: A brand new Java Library Plugin. Use this when building a component intended to be used as a dependency from another project. It provides a strong separation between public (exported) and private code which not only gives great performance benefits (because consumers’ compile classpaths are smaller), but also an architectural tool for library authors.

Put these together on our perf-enterprise-large benchmark Java project, and compilation time after a method body change is reduced from 2.5 minutes to 9 seconds! Let’s put that in perspective:
screen shot 2017-01-25 at 1 59 07 pm

It is not just large projects that reap the benefits, for example the same use case for Apache Polygene was reduced from 14 seconds to 7 seconds. Huge kudos to our performance team for delivering such massive performance improvements with this release.

Now, with your help and guidance we’ve been able to made a couple of highly-requested code-quality plugins improvements:

  • The JaCoCo plugin now allows you to enforce code coverage metrics and fail the build if they’re not met.
  • The default version of JaCoCo used by the JaCoCo plugin has been raised and the plugin is now Java 9-ready.
  • The Checkstyle plugin now allows a maximum number of warnings or errors to be configured.

A special thank you to those who voted and contributed to these issues.

The community’s voice clearly indicated the need for verifying JaCoCo code coverage metrics. The JaCoCo plugin in Gradle 3.4 verifies code coverage metrics and will fail the build if code coverage falls below a configurable threshold. The plugin is also fully prepared to run on Java 9.

Last but not least, we’ve made it more convenient to let Gradle know when you want a build scan — just use --scan (or --no-scan if not). No need for the “magic” system property -Dscan.

We hope you’re able to build happiness with Gradle 3.4, and we look forward to your feedback via Twitter or on GitHub and sharing other amazing features in 2017. Happy new year from the Gradle team!

Check the full 3.4 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.4 RC1 quickly by updating your wrapper properties:

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

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

Reporting Problems

If you find a problem with Gradle 3.4 RC1, please file a bug on GitHub Issues adhering to our issue guidelines. If you’re not sure you’re encountering a bug, please use the forum.

1 Like
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 projects.

There is a typo in the release notes:

Now, with your help and guidance we’ve been able to made a couple of highly-requested code-quality plugins improvements:

should say “able to make”.

It would be helpful if the Incremental Java compilation documentation would include some sample code showing how to easily enable it for all modules applying the java plugin instead of just linking to the JavaCompile docs. One less hurdle preventing users from trying out the new feature.

I raised issue #8120 over at spring-boot regarding deprecation warnings.

This isn’t 3.4-rc-1 related but it would be nice if you could take a look at the Having the ability to see what triggered dependency resolution topic and give me some feedback about whether or not my assumption is correct.

The thing is that our huge (or “bigly” in newspeak) in-house project takes about one minute of configuration time and it’s getting worse with every additional spring-boot application.

I guess we are not the only ones suffering from this spring-boot-gradle-plugin problem and assume that most people simply think that the slow startup is Gradles fault. You could probably sort this out with the Spring folks directly.

1 Like
4

Thank you @huxi for bringing the performance aspect of community plugins up. We definitely want to reach out more and we could use your help: Could you create a skeleton of your project that reproduces the performance problem without exposing too much about your internals? That would help us profile and make suggestions to the Spring team. Alternatively I’d be happy to walk you through a profiling session to get some data from your real app.

5

Is this release candidate version going to make it to SDKMAN!? The 3.3-RC-1 is still there and 3.4-RC-1 hasn’t made it yet. I haven’t noticed much, if any, lag time in the past. Updating the wrapper in a branch is fine for projects, but SDKMAN! has been nice for testing a bunch of one-off experiments with the new version. Is this dependent on @vermeulen_mp due to his association with both?

6

for different reasons it wasn’t released automatically during our release process. I pinged the sdkman author and it should be available soonish.

cheers,
rené

7

The new configurations disallow direct resolutions and throw an exception,
Resolving configuration 'implementation' directly is not allowed

This breaks the gradle-versions-plugin as it cannot resolve the current dependencies to determine if updates are available. Can you provide insight for why this restriction was made?

I believe a solution is to clone the configuration and call setCanBeResolved(true). That might be restricted by validateMutation, though.

8

This restriction was made as a very first step towards separating configurations (a badly named, huge god object atm) into three things:

  • Buckets for declaring dependencies
  • Queries, e.g. to be used to provide a classpath for a compile task
  • Publications to be used by downstream projects

The buckets e.g. implementation are not meant to be queried. You can create another configuration that is resolvable and depends on implementation which is essentially the most basic kind of “query” - querying just one configuration. We will add more intuitive APIs than creating new configurations for this purpose in the future.

9

A lot of nice changes in this release.
The new JacocoCoverageVerification is a welcome addition, we’ve been using workarounds for a long time.
Unfortunately there is an issue with the reporting tasks - they ignore the inclusion/exclusion patterns used by JacocoTaskExtension.
It’s not a new problem, but with coverage verification it will become more obvious.
If include/exclude patterns are only applied to the agent, but not the reporting tasks, it effectively lowers coverage statistics. Excluded classes will be reported with 0% coverage.

10

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