I like the idea that a plugin is responsible for one thing. It is
clearer what problem the plugin should solve. If maintenance of these
plugins is an issue, so IMHO, putting the code of all these plugins in
one repository could be a good compromise.
Sandra
Am 13.10.26 um 17:49 schrieb Delany:
What about keeping it 4 plugins but consolidating into 1 repository with a
lock-step release cycle?
A good deal of conceptual clarity comes from having each plugin with its
own goals and configuration and documentation.
When I'm ever concerned with the clean plugin, I don't want to see anything
to do with the deploy plugin, for instance.
So the POMs stay the same, but the management gets simpler.
You can avoid creating a chimera.
Delany
On Tue, 13 Oct 2026 at 17:31, Hervé Boutemy <[email protected]> wrote:
"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]
