On 24 Feb 2014, at 10:48 am, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
> On Sun, Feb 23, 2014 at 3:25 AM, Ioan Eugen Stan <stan.ieu...@gmail.com> > wrote: > Hello, > > Short version question: What would it take to make gradle build with > groovy 2 - (before Debian Jessie Freeze at start of this November) ? > > Short answer: we can't switch to Groovy 2 without breaking compiled plugins, > and we have a strict backward compatibility standard for minor releases. > > Since we haven't deprecated support for Groovy 1.8.6, it's unlikely we'll > remove support for this version in Gradle 2.0, our next major release. > > Instead, I believe the plan is to introduce the ability for Gradle to handle > multiple Groovy versions. If this were done, it _should_ be possible to build > and use Gradle on a platform that does not have 1.8.6 support (perhaps with > some tweaks to enable this). But adding this ability will be a non-trivial > undertaking. It is. We can chop this up into smaller pieces, though. Here’s a potential plan: 1. Change the Gradle build to create binaries against both Groovy 1.8.x and 2.x. That is, we’d create two variants of each distribution, with each variant supporting only a single version of Groovy. At this stage, the Groovy 2 distributions would be completely experimental and not be published anywhere. 2. Add some way to declare which version of Groovy a build script requires. Default would be 1.8.x. 3. At runtime, assert that the Groovy version baked into the distribution is compatible with the version that each script requires. 4. Change the plugin and script classpath resolution to infer the Groovy version required, from the dependency meta-data. Assert that the Groovy version baked into the distribution is compatible with what each plugin requires. At this stage, it would be possible to build and use the Groovy 2 Gradle distribution, provided your build scripts are compatible with 2.x and all your plugins have been compiled with Groovy 2 (or don’t use Groovy). Gradle will detect when you run a build if this isn’t the case. Then, we can start to improve things: 1. Change the Gradle CI pipeline to run the appropriate test suites against these variants. 2. Change the Gradle release promotion steps to publish the Groovy 2 variants. 3. Change the Gradle wrapper and tooling API to select the correct variant for a given build. 4. Introduce a Gradle plugin plugin and have it build and publish Groovy 1.8 and Groovy 2 variants of each plugin. 5. Change the plugin and script classpath resolution to select the appropriate plugin variant based on the runtime variant being used. At this stage, we’d have full support for both Groovy 1.8.x and 2.x, and we’d choose the appropriate variant based on what the build needs at runtime. Then, we’d probably deprecate the Groovy 1.8x runtime and eventually remove it. Over time, we’d also reduce some of the coupling between Gradle API and Groovy version, so that less of the runtime will need to be published as multiple variants. We would also generalise the classpath resolution into general-purpose variant support for Groovy based components (and Scala based components too). > > If you're still keen to help out we'd welcome the contribution, and I'm sure > you'll find others who would also be willing to pitch in on this change. > > Daz > > I am interested in helping out. > > Long story, some of my reasoning and refined questions: > > I'm a software consultant/developer and I work mostly with Java/Groovy > and Maven. I'm also a Debian contributor and would like to see better > JVM support on Debian - going for Mainainer. I think that Groovy > (especially with Grapes) has a very important role, I won't go into > details here. > I also believe that many Debian maintainers prefer Gradle over Maven - > it seems that Gradle applications are easier to package with respect > to the Debian Policy which mandates all dependenies must also be > available as Debian packages. > > Debian (and Ubuntu) are very popular as development and production > platforms and people generally prefer and trust packages from main > distribution (stability and security). With this in mind, the two > distributions offer a very good distribution channel and will > encourage adoption of both Gradle and Groovy and the JVM. > > That being said, I would like to get Groovy 2 in Debian in time for > Jessie which is this November .Debian has a release cycle of ~ 2 > years, and no new major versions are added in the mean time so if it > doesn't make it now, it won't make it until the next release. > > The only problem is that Groovy 2 is built with Gradle which in turn > has a dependency on Groovy 1.8.x which is not good. Maintaining two > Groovy versions in Debian comes with a very big cost so the only > conclusion is - upgrade Gradle to Groovy. > > I'm a very good Java developer, ok with Groovy with ~ zero Gradle > knowledge and I would like to put some time in making the upgrade > provided: > > - it's doable (no major braking changes to the current version) > - you (community) are willing to integrate the changes upstream > - you (community) are willing to lend a hand to get me started - some > steps, what are the requirements for integrating the changes, etc. > > p.s. I may be biased on the above, but there is truth in there. > > -- > Ioan Eugen Stan > 0720 898 747 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
