1

The first Gradle 1.12 release candidate will be released in the next few days. It is the last intended release of the Gradle 1.x line.

In 8 or so weeks, we will be releasing Gradle 2.0.

Since releasing Gradle 1.0 on June 6th 2012, we’ve released 12 subsequent significant updates at an average of a new release every 8 weeks. We’ve also maintained an extremely high degree of backwards compatibility. The vast majority of builds written for Gradle 1.0 work without modification when run with Gradle 1.12. This is not by accident. When fixing bugs, improving features and even adding new features, the Gradle development team frequently makes compromises in order to maintain backwards compatibility. This allows us to get new features, fixes and improvements into your hands faster without a heavy upgrade cost. Gradle helps teams around the world continuously deliver software and we work hard to continuously deliver Gradle itself to those teams.

The change in major version number from 1 to 2 for all future Gradle releases is a technical signal that we are setting a new compatibility baseline. On the 1.x journey, we have deprecated features that are no longer useful and/or have been superseded. Gradle 2.0 will drop many of these deprecated features, but not all.

The version move does not change the incubating feature policy. Some of the incubating feature set will be promoted to stable for the 2.0 release, and the rest will continue to evolve as the particular feature demands. In short, it’s business as usual with regard to feature incubation.

If your build works with Gradle 1.12 and does not issue any deprecation warnings while building, it is extremely likely that your build will continue to work just fine with Gradle 2.0 and continue to work until Gradle 3.0. Only features that have been formally marked as deprecated will be removed, and typically only those features that have been deprecated for at least two releases of Gradle. The majority of builds will either just work with Gradle 2.0 or require a small amount of work to replace use of features that were removed.

One significant change that is coming in Gradle 2.0 is the upgrade to Groovy 2. This should not cause compatibility issues for the vast majority of users, but it is a significant change. This change primarily concerns plugins as they are compiled with and against the version of Groovy that Gradle provides. Groovy 2 is for the most part binary and API compatible with Groovy 1.8.x. However, some exotic uses of Groovy may not be compatible. Some plugins may need to be rebuilt with Gradle 2.0 in order to work in Gradle 2.0 builds. Most plugins will just continue to work fine as is.

The move to Gradle 2.0 allows a lot of legacy “weight” to be jettisoned from Gradle, making the development of future features easier and faster. The “2.0” version move is a technical signal and not a marketing one. You can expect regular delivery of new features for the 2.x line, in the same non disruptive way that they were delivered for 1.x. We are serious about our commitment to stability and making it easy for users to “stay current” in their Gradle usage.

We would like to strongly encourage you to try out the release candidates of Gradle 2.0 when they become available and give us your feedback. We put Gradle through rigorous testing after every commit, but the feedback we get from real world testing is extremely valuable. By testing out the Gradle 2.0 release candidates on your build and letting us know of any problems, you will make it easier to upgrade your projects to Gradle 2.0 final.

If you’re wondering what features are in store for Gradle 2.0 and beyond, more information will be forthcoming closer to the release. You can also get the information direct from the source at the Gradle Summit in Santa Clara on June 12th and 13th.

The entire Gradle development team will be there to chat with and to present sessions on various different Gradle topics, including the future roadmap and direction of the Gradle platform. Space is limited. Get your ticket now.

Lastly, thank you to you for being part of the Gradle 1.x story. The feedback, plugins and code contributions provided by the Gradle community goes a long way to making Gradle what it is today. We hope you’ll continue to be part of the community and be a part of this new era in the evolution of Gradle.

2

Any status on the 1.12 RC? Release notes? Nightlies are showing 2.0 as a version.

3

RC is working its way through the build pipeline.

4

So, will gradle 2.0 at last have support for “provided” scopes?

This is the most voted feature of all times on the issue system and was opened four years ago now…

I mean, I use Spring’s propdeps plugin which does that for now, but why isn’t it yet in “core gradle”? 1.12 rc* don’t seem to have it either.

5

Awesome, I am really looking forward to Gradle 2.0, Groovy 2 is a massive improvement.

When you say Groovy 2, do you have a specific version in mind?

Groovy 2.1 brings the invokedynamic and Groovy 2.3 is the only one that officially supports JDK8. To me running on Groovy 2.3 is a must have.

6

We’ll move to the latest we can. If that’s not a JDK 8 compatible version initially, then we will move again when we can.

7

I am very much looking forward 2.0

8

I am very much looking forward 2.0

9

Hi FGE,

Gradle 2.0 won’t have a “provided” dependency configuration.

It comes down to two things:

  1. We think ‘provided’ as implemented in the Maven world is not good enough 2. There are existing workarounds that fill in the gaps in the meantime

Point #1 deserves some context. In essence, “provided” is a weak contract. There are no real of semantics about what provided means in practice outside of the app server domain (which is why our ‘war’ plugin supports it). Granted, it is repurposed to be used in other domains, but there are a host of problems with this. That is, there are no semantics about how/what the provider is expected to provide. Moreover, it conflates the description of how something is to be constructed with how something is to be used.

We are working towards a richer model that will address these problems and provide richer modelling primitives that could then be translated into a Maven provided scope if the publication is to be serialised to Maven format.

If you want to reignite this debate, the dev mailing list is probably a better medium for such a discussion.

10

I am sorry but that’s still no reason.

Issue 784 has been opened for 4 years, even more than that, it is the most voted issue, the most watched issue. Your users are expecting that.

Technical excellence is all right all good, but when it comes to the expense of users wanting to achieve things, it just gets in the way.

I don’t know about maven’s internal implementation of it and, frankly, I don’t give a damn, nor do the 100+ voters of issue #784. I just know that I have to ‘compile()’ depend on JSR 305 headers, and have to use an external plugin to be able to only ‘provided()’ it.

If point #1 were that valid, we would still be waiting for HURD to be there, would all program in Scheme and would use a fully compliant OSI network stack. But we don’t.

11

Our project wants to use JSR 305 as well. Luke, can you point me to the preferred “existing workaround”? I’ve Googled it and it looks like several people have tried several different things; I didn’t get a sense of “this is the way to go”. Thanks.

12

@jbisotti I use the propdeps plugin from Springsource and it works pretty well: https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin

Hoping that it will work with 2.0…

13

Not wanting to fan the flames here, but JSR 305 is a good example of what I’m getting at in my original comment. Using ‘provided’ for this makes no sense (where is this provided and by who?), but it happens to work.

14

OK well, as I said I am unaware of how this works internally; for me, “provided” is just “you’ll need this for compiling, but not at runtime”. And it works for me this way.

How do I get it wrong? What more is involved?

15

Provided semantically means that you expect that thing to be provided by something when this thing is used. In the J2EE space this is the app server. The “implementation” that everyone is familiar with matches what you describe, but that’s really by coincidence.

So currently, the metadata (assuming you are publishing POMs) for your component states that it requires these annotations at runtime, but that they are expected to be present by some mechanism (i.e. the component doesn’t ship them).

These kinds of ambiguities and semantic abuses are a big problem in complex dependency management scenarios.