you just gave me the reason for -1 on merging plugins into core = the chicken and egg question with plugin plugin = core would require plugin plugin
= one of the aspects of getting plugins into core that I felt but was not able to put my finger on yet On 2026/10/13 20:58:29 Gerd Aschemann wrote: > 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 -- [email protected] -- https://aschemann.net > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
