hmm, why not going one step further and importing them in maven (for defaults - maybe except ejb/war which are no more mainstream now but jar pipeline clearly is)? we could even drop the specific classrealm for them once done with a few refactoring and it will help to promote shared tooling as a service in maven 4.
know it was already discussed to bypass classrealm and potentially have a graalvm maven build at some point but think it is not crazy to not consider them external plugins since they arent and overriding them would be getting a new maven release which is good too and simplifies part of them and the release train. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le mar. 13 oct. 2026 à 22:59, Gerd Aschemann <[email protected]> a écrit : > Had the same thought, just one question: are there cases where a fix in > one of these four plugins had to reach users faster than a core release > could have carried it? > > I looked at the release history of the five repositories involved (git > tags, GA only, pre-releases excluded): > > core/maven 28 releases since 2020, median gap 54 days > maven-install-plugin 8 releases since 2020, median gap 128 days > maven-clean-plugin 7 releases since 2020, median gap 184 days > maven-deploy-plugin 7 releases since 2020, median gap 198 days > maven-resources-plugin 6 releases since 2020, median gap 241 days > > On the median, the coupling costs nothing: the core has been releasing > three to four times more often than any of these plugins. Taking every > plugin GA since 2015 and asking how long it would have had to wait for > the next core GA gives a median of 52 days over 34 releases. > > What worries me is the tail, not the median. Of 27 core gaps since 2020, > 8 were longer than 90 days and 2 longer than 180, the worst being 291 > days (3.9.9 on 2024-08-14 to 3.9.10 on 2025-06-01). A clean plugin bug > found in September 2024 would have waited nine months for a release. > > Two things these numbers do not cover: > > - "released" is not "adopted". Bumping a plugin version in a POM is a > much smaller ask of a user than moving to a new core version, so the > effective latency of a built-in fix is longer than the release gap. > > - there is no Maven 4 track record to extrapolate from: the 4.x line has > 25 tags and not one GA among them. The 54 day cadence above is > essentially 3.9.x maintenance, which may say little about how often a > 4.x core will ship once it is out. > > Regards, > Gerd > > > On 13. Oct 2026, at 21:58, Sylwester Lachiewicz <[email protected]> > wrote: > > > > .. consolidate to one repository.. maybe simply into apache/maven ? as > > build-in plugins? > > > > Sylwester > > > > On Tue, Oct 13, 2026 at 5:50 PM Delany <[email protected]> > wrote: > > > >> 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] > >>> > >>> > >> > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 <+49%20173%203264070> -- [email protected] -- > https://aschemann.net > >
