.. 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] > > > > >
