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]
