I think it would be great if someone can document the jakarta migration via bytecode adjustment process including a Groovy example. For sure, there will be folks who may not want to follow the typical javax to jakarta evolution path. If using Groovlets, they would need to run the tool(s) on the groovy-servlet jar and their own generated classes.
I think though, by far the most common scenario will be folks wanting to write groovlets (or long-hand servlets) and wanting to deploy them to the newer servers. For Groovlets, there isn't really any package imports required, so it's just a deployment issue. But for those writing long-hand servlets (maybe extending Groovy's AbstractHttpServlet or maybe extending HttpServlet and using ServletCategory) they will likely want to use all the updated package imports. So, what was recently committed seems the best way forward to me. And it is a jump in Spec versions but as mentioned earlier, you can use Groovy 4.0.x version of groovy-servlet. I have a repo which shows that here (using Jetty): https://github.com/paulk-asert/groovy-servlet-hello ====== Groovy 4 Groovy Server Version: 4.0.24 groovy-servlet jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/org.apache.groovy/groovy-servlet/4.0.24/6d57aea3d60893307ad28021d733c40cb161b523/groovy-servlet-4.0.24.jar jetty API jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.toolchain/jetty-servlet-api/4.0.6/959c5d83d08f5cddf56caff749e48b735193191b/jetty-servlet-api-4.0.6.jar Effective Servlet Spec version: 4.0 You have invoked this Groovlet 1 times. ====== Hybrid Groovy Server Version: 5.0.0-SNAPSHOT groovy-servlet jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/org.apache.groovy/groovy-servlet/4.0.24/6d57aea3d60893307ad28021d733c40cb161b523/groovy-servlet-4.0.24.jar jetty API jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.toolchain/jetty-servlet-api/4.0.6/959c5d83d08f5cddf56caff749e48b735193191b/jetty-servlet-api-4.0.6.jar Effective Servlet Spec version: 4.0 You have invoked this Groovlet 1 times. ====== Groovy 5 Groovy Server Version: 5.0.0-SNAPSHOT groovy-servlet jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/org.apache.groovy/groovy-servlet/5.0.0-SNAPSHOT/55f8597a7235502068dd5702c08139fcd8386c17/groovy-servlet-5.0.0-SNAPSHOT.jar jetty API jarfile:/Users/paulk/.gradle/caches/modules-2/files-2.1/jakarta.servlet/jakarta.servlet-api/6.0.0/abecc699286e65035ebba9844c03931357a6a963/jakarta.servlet-api-6.0.0.jar Effective Servlet Spec version: 6.0 You have invoked this Groovlet 1 times. ====== Cheers, Paul. On Sun, Dec 22, 2024 at 1:43 AM MG <mg...@arscreat.com> wrote: > > Hi Jochen, > > that sounds like a good idea, but I am just wondering if ppl who are in this > situation might not potentially have other (Java) libraries in use, for which > they would need to do the renaming of the class references also. > So maybe having a chapter in the Groovy documentation which explains how to > do this so it plays well with Groovy might be the more generally applicable & > easier to do option ? > > (Note: "plays well with Groovy" might not be an issue here, but I am just > thinking back to the pains of Minecraft obfuscation not working with Groovy > generated bytecode) > > Cheers, > mg > > > On 20/12/2024 17:52, Jochen Theodorou wrote: > > On 20.12.24 14:24, Paul King wrote: > > Well, that would be the idea. Maybe not recommended, but currently you > can still use the 4.0.x groovy-servlet jar with Groovy 5. At least for > Groovy servlets with a simple Jetty server test I just tried. > > You certainly wouldn't want both the 4 and 5 groovy-servlet jars in > your classpath/modulepath and perhaps there might be reasons later to > not allow mixing those versions. > > > there was already the suggestion to basically offer both and just use > bytecode transformation (renaming class references). If groovy-servlet > is the only place impacted by this it looks like an option to me. Wdyt? > > bye Jochen > >
