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
