On Thu, Apr 16, 2026 at 6:53 PM Christopher Schultz <[email protected]> wrote: > > Rémy, > > On 4/16/26 7:50 AM, Rémy Maucherat wrote: > > On Thu, Apr 16, 2026 at 12:03 PM Mark Thomas <[email protected]> wrote: > >> > >> On 16/04/2026 10:53, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> So I wanted to test the latest "small" local LLMs + OpenCode with > >>> something real, and my (lucky ?) victim was the Tomcat Maven plugin. > >>> It was too far gone to have any further use, since it had been > >>> untouched for 10 years. Also me being such a huge expert in Maven > >>> makes things quite interesting. > >>> > >>> The plugin should now be a little bit more useful, and it works with > >>> Tomcat 9, 10 and 11 (the main goal obviously). > >>> > >>> Previously, the plugin saw regular releases, somehow, *not tied to the > >>> Tomcat lifecyle*. This is despite the main feature being to produce a > >>> bundled Tomcat and a webapp as an executable JAR, thus suffering from > >>> all the issues (bugs + security) from the bundled Tomcat. > >>> > >>> Since the plugin has to hardcode a Tomcat version number, I made the > >>> change to align its version with the Tomcat version it would actually > >>> use, to know the CVE situation easily. If we wanted to make releases, > >>> we would need to do one release per Tomcat branch per release cycle. > >>> This is not realistic. > >>> > >>> My proposal is thus to keep the repository open for PRs and bugfixing, > >>> update the version numbers regularly as mandated by dependabot (except > >>> that Maven update to 3.9.14. that's a bad move ...) but requiring > >>> users to build it from github after setting up their desired Tomcat > >>> version, rather than actually releasing it. So: low effort, no > >>> releases. > >>> > >>> Comments ? > >> > >> Great news/ I was only wondering this morning how you were getting on. > >> > >> I'm no Maven expert either but could be not set things up (with > >> properties or similar) so we specify a tested version but users could > >> override that to use a different Tomcat version if they wanted for their > >> project? I know Spring Boot does something similar for its Tomcat > >> dependency. > >> > >> If the above were possible then releases of the plug-in should be > >> practical. > > > > I looked at it, and I don't think you can, the version gets into the > > plugin's dependencies, and that's that. I tried by reverting back the > > version number of the plugin to not be tied to Tomcat (back to > > 3.0-SNAPSHOT basically), but it did not help. > > > > I think it was the same before: > > https://tomcat.apache.org/maven-plugin-2.2/ > > and > > https://tomcat.apache.org/maven-plugin-2.2/executable-war-jar.html > > So you can specify the plugin version but that's it. > > > > First, let's see if users are interested and if PRs and issues fixes > > come in. And maybe someone will have some idea ;) > > Is it possible to use the maven plug-in against pre-release versions of > Tomcat that have been staged -- e.g. during the voting period for releases? > > If so, I could add some validation that e.g. a smoke-test application is > able to build and run successfully as part of the release-testing > process, all automated. > > (I've been looking at my release-testing script and frowning that it > doesn't do anything at all with the Maven-related stuff.)
I would say it is not great for smoke testing. The problem is that when you start the server in the pom, you have to fork it (to run it in the background), but then Maven thinks the goal is finished (the server is still starting in the background, actually) and proceeds immediately with the next goals in the lifecycle. I think I need to add a "wait" goal ? So it might not be so easy. I'll see how that goes with CI to see if it's realistic. Getting back to the original topic, I'm still not very motivated by having real releases of this. The only realistic option I can now think of is to simply build and deploy the artifact as part of the Maveny stuff done is in res/maven, and vote it as part of the Tomcat release. Rémy > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
