After busy days I finally blocked some time to share my opinions about this:
I would not break with the basic plugin architecture of Maven and leave
it with what it does: "only" running a lifecycle and call the plugins
which were configured into it via the pom.xml. Putting plugins into
Maven would start the discussion about "why those, but not others". We
had this in some kind of ways some time ago about which plugins should
residate in the Super-POM (which always rises asking myself if I like
the Super-POM or not - but this is another topic). The defined versions
and plugins in "mvnup" are similar (and produce maintenance effort).
I would also not put the plugins into one git repository with a combined
release - why do I (as a user) need to raise the number of the clean
plugin when only a bugfix in the deploy plugin was fixed? A common
repository for those would result in bondage them, like we have on each
plugin and its site currently (we can't fix typos on a site without a
release of the plugin...) Longer builds were already mentioned by Slawek.
The motivation of Hervè's idea is maintenance on users and Maven's side:
As a user I like the approach that one plugin does one thing - on the
other side I can't rely on this as the creator of the plugin defines
what and how much the plugins does. For example the PMD report goal also
calls a build if no build-check-result file is there. You could argue
that it's a prerequiste to generate a report, but you could also argue
that when there is no check-file then the result is empty or the goal fails.
About maintenance: At my work I update the plugins in our META-POM once
a months, but in general it doesn't matter if I miss a month, because in
many cases the plugins just work. And three more lines for a version
would not reduce or remove the "configuration" section.
With focus on us a Maven team, I think we have to differiate:
* Maintaining ASF/Github stuff: This is quite some pain as Github does
not support some kind of "different projects with multiple repositories
inside an organization", so to have the same workflow in every Maven
(but not other ASF) repository we have to it in every repository. And as
we don't have the same workflow in every repository Dependabot kicks in
with a lot of "Setupjava"-actions etc. as well as updating all
repositories when we release a new version of our
maven-gh-acctions-shared. Maybe we can tune dependabot here to
auto-update them. So far we sometimes only have to check on
release-drafter updates, but not the other actions.
* Dependabot in general: I'm not very into Dependabot, but as mentioned
by others we have to do a lot of "build is okay? okay merge" dependency
updates and "no we don't want this (major) version for the plugin. Maybe
we can define a general dependabot setting for this, like "if the branch
is a Maven 3 plugin, we don't want Maven version x, we don't want SLF4J
version x+" so we don't have to do it in every repository. But I'm
afraid this won't work due GitHub layout as mentioned in first point.
What already helped (me) to list open Dependabot PRs was the "dependabot
PR page" [1] created by Gerd, but ofc this does not help if decisions
have to be made and applied (do we want this upgrade or not) or broken
builds have to be investigated. The broken builds are a rising issue
from my feeling. I know it has to do with AI overloading Jenkins and GH
(which is a problem Slawek is working on), but often due not so well
written ITs when it comes to assertions. Don't get me wrong - I like our
test coverage and ofc I want to have a test failed due cating a bug but
rather an let it through. We have several ITs which heavily rely on the
log output. Earlier this year I updated a lot of ITs do rely on variable
verion numbers, esp. of maven plugins so they are also picked up on
parent updates, but this is/was only on messages with those numbers.
* The voting process is part of the ASF and ofc the more releases you
do, the more votes you have.
The last point brings us back to the initial idea: Reducing the number
of plugins / libraries and with that reducing the mainteance with
everything connected to it.
Rather by thinking about the size of a plugin, maybe think about the
functionality. What do I mean by this.
For me combining the clean and the install looks strange, because they
don't have anything in common. But combining install and deploy makes
totally sense for me, because they both copy the build artifact to a
repository. So maybe we can combine those into one. Esp. in terms of the
deploy plugin I'm curious if its fully working. For me at work its
working fine, but we only deploy to the company own nexus repository. In
terms of deploying to e.g. Maven central it can't be used but other
tools and plugins needs to be used from what I've read on Slack/Mailing
lists. So does it really holds the promise we give with it?
With the current discussion about copying archiver code into the jar
plugin to remove its depenency makes we also curious. As already
mentioned in the discussion I'm not sure that it brings a benefit that
the jar plugin will behave differnt in terms of archiving in the future
than all other archiving plugins. So we might want to (I guess this was
done in the past and there reasons to not do it) to have a more dynamic
archiving plugin which can handle also ejbs (yes they are still used in
slow moving enterprises and EJB is still an optional spec of Jakarta
EE), ears, wars and all the others. Maybe by moving the configuration
out of the pom.xml into format-dependent config files which are copied
in the archive. This might be a naive thought of a less-tech person -
but I'm just thinking in terms of reducing mainteance and in terms of at
least five of the ten packaging plugins.
We might also want to look at how plugins work or how stable they are:
Let's take surefire: It was heavily refactored due the fact that the
JUnit Jupiter engine can handle all former individually supported
testing tools. I personally was confused why failsafe exists as my
thought was that's its literally the same as surefire. However, in a
night session with Romain and Guillaume some weeks ago, I've learned
that from Maven's POV ITs are something totally different that in my
(and a loooot of other peoples) knowlegde. So there are reasons (which I
can't tell you now, because I didn't have time to dive deeper into
this). Another example might be the JMOD plugin: Since Java 24 this
heavily depends on the JDK if the JDK ships the JMOD folder or not. And
from my understanding (I don't know nothing about creating custom Java
runtimes except the fact that it's possible) it has a releationship with
Jlink (which is another plugin). As mentioned above: What a plugin does
is primarly a design decision and as every decision there are pros and
cons to do so. Iirc the compiler plugin gets changed with its new major
version to also (or better?) support other compilers than the JDKs one.
This brings more freedom to the user, but most probably more mainteance
effort for the team.
So about the idea of merging the four plugins mentiones here. I would
* keep clean independent (esp as it has its own lifecycle) or remove it
at all if we define that the clean lifecycle is overhead and could be a
simple function of Maven. But I don't know what people also do during
clean lifecycle. Maybe they hang in other plugins to clean up
development environment.
* keep resources independent, but take a look in how far it differs
frome "remote-resource" plugin. According to plugin page the both copy
resourfces into the output folder.
* think about merging install and deploy plugin into deploy plugin as
they both deploy the final artifacts to a repository.
Aside on this: Continue our work on improving the general workflow, e.g.
tuning dependabot.
This were my two (maybe more) thoughts on this.
Have a great weekend everybody
Matthias
[1] https://aschemaven.github.io/maven-simple-reports/dependabot-prs/
Am 13.10.2026 um 17:31 schrieb Hervé Boutemy:
"why" is a very good question:
happy to start writing all the reasons I have, and let others add anything pro
or against
my reasons for that change:
- as a user, yes, only one plugin version to manage instead of 4 (less
Dependabot PRs, version in my pom.xml...)
- as a Maven PMC member maintaining 4 plugins if 4 Git repositories with 4
votes, I'll have only 1
- code for install and deploy plugins are so similar that each time we modify
one, we modify the other and do 2 releases
- these 4 plugins are quite small: break one goal when fixing another is IMHO
pure theory
- on the branch for Maven 3 plugins vs branch for Maven 4 plugin API (that we
currently have as beta), Id' be happy to have that simplification in the
process: one single Maven 4 plugin, one stone, multiple birds
so many small problems, no big rock
please add any pro or cons
Regards,
Hervé
On 2026/10/12 19:08:33 Maarten Mulders wrote:
Hi all,
My first thought is: "why?" What benefit would it give? A few lines less
XML in a POM? Less upgrades? I think most Maven users write their POM
once and then use tools like Dependabot or Renovate to keep the plugins
up-to-date.
Additionally, I have a few concerns with this idea.
1. As a Maven user, if one "part" breaks with an upgrade, you cannot
upgrade - this would prevent usage of new features inside other "parts"
that you could be waiting for.
2. As a Maven developer, wouldn't this new "all-in-one" plugin become an
unnecessary large codebase?
I'm not saying I agree or disagree; I'd first like to know the "why".
And I'm curious what your ideas are regarding the concerns I brought up.
Maarten
On 09/10/2026 02:36, Hervé Boutemy via dev wrote:
while we are discussing structural changes for Maven 4 longer term, I think
instead of maintaining these 4 core plugins in a 4.x branch for these base
clean/resources/install/deploy operations, it may be the right moment to
consolidate them into one single plugin
no idea how to call this plugin
with its clean, resources, testResources, copy-resources, install, install-
file, deploy and deploy-file goals
see https://maven.apache.org/plugins/
compiler, site and surefire as independent plugins, even when we'll do a 4.x
branch, remains IMHO more reasonable
WDYT?
Hervé
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
