Plan for Gradle 7 release

[f4lco]

#214 has introduced a build job that guards against regressions with the Gradle 7 release candidate. The PR has also removed the hard-coded version of Groovy, which allows to re-use the same plugin sources for building against both Groovy 2 (Gradle 6) and Groovy 3 (Gradle 7). However, as @chali points out, this may not allow to actually publish and use the compiled plugin artifacts from within the same build job because of the binary incompatibility of Groovy 2 and 3.

I would highlight one thing which might not be very obvious if you plan to release a future version of gretty using Gradle 7 it might set a requirement that the consumer project has to use Gradle 7 too. Once the plugin switches to Gradle 7 all code is compiled against Groovy 3 which is not binary compatible with Groovy 2 so using the plugin in older projects will lead to failures.

Likely, we need to resort to publishing several plugin variants, which is in principle possible using experimental Gradle features as described in the Gradle 7 RC 1 documentation.

TL;DR: With advent of the new Gradle version, we need to publish several artifacts with different binary compatibility wrt Groovy, because likely we cannot drop Gradle 6 support immediately. Within this ticket, we should settle on a way to do it, and also adjust Gretty's build process.

[boris-petrov]

@f4lco - I'm not sure I understand. As @chali confirmed we can simply build Gretty 3 and 4 with Gradle 6 and that release will support both Gradle 6 and 7. Why are you saying that we need to publish several plugin variants?

[f4lco]

@boris-petrov I got quite the opposite vibe from #214 (comment) 🤷 We might be able to use the same Gretty sources to compile with Groovy 2 and 3, but if they are binary incompatible, I do not see a way around different artifacts / variants containing different class files for the respective Groovy versions.

[boris-petrov]

@f4lco - I just ran our app on Gradle 7 RC 2 with Gretty 3.0.4. It ran fine. I saw it was using Groovy 2.5.14, not sure why. But does that answer your worries?

[f4lco]

@boris-petrov unsure, depends on what you mean by "using". Yes, it might be possible that Groovy 2 was still on the classpath. And maybe that's also a future topic, not of immediate relevance: Groovy 3 might diverge more in the future, increasing the incompatibilities with Groovy 2, and as @chali pointed out, Gradle may have different requirements in the future.

[boris-petrov]

I'm also not sure what I mean. 😄 When I run appStart, I get the following output:

> Task :prepareInplaceWebApp
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/boris/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.14/f0a005fb21e7bd9b7ebf04cd2ecda0fc8f3be59d/groovy-2.5.14.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

It's the same on Gradle 6.8.3 and on Gradle 7 RC 2. This is at compile-time though... not sure about runtime. And I don't even understand where this Groovy version comes from... but in any case Gretty seems to work fine.

As for what you say about Groovy 3 diverging - that's for sure the case. For now we're lucky that Gretty (built with Gradle 6) seems to work just fine on both Gradle 6 and 7 so that's that. When that stops being the case - hopefully not in the next few months - we'll drop support for Gradle 6 and call it a day. :) Are you fine with that?

[chali]

@boris-petrov @f4lco to clarify my comments and concerns a bit. I was able to use a plugin published with Gradle 6 and compiled with Groovy 2 in Gradle 7 projects. There might be some changes required but it worked. My concern is that if a plugin project will move to Gradle 7 itself it will cause to produce groovy 3 compiled code and it will not work if this plugin is applied in Gradle 6 consumer. A concrete example. If you release Gretty plugin with Gradle 6 consumers should be able to use it a Gradle 7 projects. If you release Gretty with Gradle 7 it won't be possible. There is a hidden relationship between the Gradle version used in Gretty project itself and what is the compatibility of the produced plugin.

I found that it is possible to make Groovy 3 compiled code runnable with Groovy 2 but it is very tedious work. You basically have to write Java instead of Groovy.

[f4lco]

OK thanks @chali for clearing this up. So I'll close this one: there's not much to plan or to do for the Gradle 7 release. My final takeaway is that once we move to Gradle 7, compile using Groovy 3, and publish that, we immediately discontinue support for Gradle 6.x (at least without investing a huge amount of work). That's something to keep in mind. Up to that point, the current setup serves us well: it guards against regressions for both Gradle versions, and publishes a plugin with good compatibility.

we'll drop support for Gradle 6 and call it a day. :)

That's fine, we just should be aware of the implications.