Rémy,

On 4/16/26 5:10 PM, Rémy Maucherat wrote:
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.

No, this is okay. I'm scripting outside the build itself, so I can just say "build my smoke-test application and run it", then my script can e.g. make some requests against that deployed application. Then I can tear it down.

I was more interested in being able to get pre-release Maven artifacts than anything else.

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.

I get it. I was thinking I'd just use the main/HEAD all the time and use it to test the Maven artifacts that are being voted on for normal Tomcat releases.

-chris


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to