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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
