one Git repository: does not change the fact that we have 4 releases, if that 's really just about Git
merging into Maven (I mean not only Git, but the release cycle): Maven is a build system based on independent plugins. Going that route creates a surprising difference, that opens many questions: IMHO, that goes too far m-plugin-plugin: that one IMHO is a different question = what is done at plugin build time (= generate plugin.xml from annotations) vs runtime (use plugin.xml but not annotations) the reporting aspect of it can stay separate to me, the key question is about these build time annotations vs runtime descriptor Merging into Maven would just make clarifications even harder On 2026/10/13 20:39:22 Guillaume Nodet wrote: > That would be nice, but the prerequisite would be to also add > m-plugin-plugin I think. > > Le mar. 13 oct. 2026 à 21:58, Sylwester Lachiewicz > <[email protected]> a écrit : > > > > .. 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] > > > > > > > > > > > > > > > -- > ------------------------ > Guillaume Nodet > > --------------------------------------------------------------------- > 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]
