If, as a maintainer of a community plugin somewhere, with advanced plugins using resolver in-depth (which has always been the trickiest aspect to support), you want to do that on your plugin: not a problem, I won't and can't force you.
As a Maven PMC member maintaining our large collection of plugins = https://maven.apache.org/plugins/ , I just want to make sure we show the default approach that should match the vast majority of community plugins = Maven 3 plugins run in Maven 4 without any issue (once they stopped being Maven 2 plugins without really knowing...) This is the step we need to have community feedback in the next 6 months at least. If any Maven 3 plugin from the community plugin is failing in Maven 4, please report, and we'll help fixing as we did in the past 6 months for all our own plugins. During that period, yes, a few plugins that really have a strong interest in Maven 4 API improvement can work on it, help us create documentation and experience. It's just clarifying default vs exception, transition plans, experience building. Matthias did a great work at documenting transition to Maven 4 for end users https://maven.apache.org/whatsnewinmaven4.html And he clearly identified that the transition for plugin maintainers still need some work: let's work on it, not a problem, as this is the future, for sure Regards, Hervé On 2026/10/09 06:46:24 Romain Manni-Bucau wrote: > Just to correct a bit your statement Hervé > > > here is no rush to create Maven 4 plugins: Maven 4 plugins is a work for > future, a target situation in a few years. > > There is from the external community because of the stable API which is an > insanely positive move - even know some writers who will not care to drop > maven 3 support due to that hell (resolver hurted a lot by the past and > costed a lot). > So while I understand the statement I don't think it is that accurate, in > particular cause maven 4 work is no more focused on the API. > > So while we make our plugins compatible with both, potentially in a single > branch, there is no need to do something special and it simplifies the > maintenance for everybody so think we missed the goal there. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via > linkedin) > > > Le ven. 9 oct. 2026 à 01:43, Hervé Boutemy <[email protected]> a écrit : > > > there is an important aspect: > > we need to clarify that Maven 3 plugins are still the normal situation > > even with Maven 4 out. > > > > There is no rush to create Maven 4 plugins: Maven 4 plugins is a work for > > future, a target situation in a few years. > > > > This message is not only for our Maven-team maintained plugins but also > > all plugin maintainers from the community. > > > > Our users community is huge, so is our plugin maintainers community: they > > need time to test, learn, transition. > > > > > > Gerd shares detailed plan before doing, instead of doing, creating a bad > > situation, then having live with it. > > Please let him fix the too aggressive move that was done: it does not > > break anything, and he's doing the work to fix the situation. > > > > > > Remember, the plan is: > > for now, we release Maven 4.0 that runs Maven 3 plugins. > > Maven 4 plugins are an exception, for example for Java Module improvement, > > where the complexity adds a real value. > > This is what provides a smooth transition: > > - for Maven users > > - and for plugins maintainers (at Maven and in the community) > > > > Once Maven 4.0 is released and we have good feedback that Maven 4 works > > well, we'll have time to plan wider plugins move. > > > > Let's avoid existing plugin maintainers confusion from Maven 4 existence: > > new plugin API is a long term plan that will happen after a few years. > > Maven 3 plugins are there to strive for years, as simple as today. > > > > Trying to go faster is counter productive. > > > > > > Thank you Gerd > > > > Hervé > > > > > > On 2026/10/08 16:30:10 Romain Manni-Bucau wrote: > > > Hmm, i'm -0 to change, I dont see much benefit. > > > > > > That said if we move to say "we don't do branches for maven 4/maven 3" > > but > > > move plugins to multimodule builds with shared+mvn3+mvn4 in a single > > branch > > > and versions (maven vs plugins) are independent then it is a real pro > > since > > > it enables to reduce backports and I'd move that to master/main, > > everything > > > else is useless noise IMHO. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > > | Old > > > Blog <http://rmannibucau.wordpress.com> | Github > > > <https://github.com/rmannibucau> | LinkedIn > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact > > via > > > linkedin) > > > > > > > > > Le jeu. 8 oct. 2026 à 18:20, Gerd Aschemann <[email protected]> a > > écrit : > > > > > > > Fair questions -- here are numbers on the fork impact, since that's the > > > > main concern. > > > > > > > > Across the 9 repos there are ~620 forks, but the relevant subset is > > much > > > > smaller: > > > > > > > > - ~74% (about 465) were created BEFORE these repos moved master to the > > > > Maven 4 > > > > line (that switch happened in 2024, March-June). Their master is > > > > therefore > > > > ALREADY the Maven 3 line. Bringing upstream master back to Maven 3 > > puts > > > > it on > > > > the SAME line those forks are on -- it reduces divergence, it doesn't > > > > create > > > > it. They need nothing. > > > > - That leaves ~155 forks created after the switch (Maven 4 master). Of > > > > those, > > > > only ~100 are active (a push in the last 12 months); the rest are > > > > untouched. > > > > > > > > So the forks that could face a one-time realignment are on the order of > > > > ~100, > > > > not 620. And even for them: > > > > > > > > - The rename does not touch fork branches -- a fork keeps its branches > > > > unchanged. > > > > - Open PRs from forks are retargeted automatically by GitHub when the > > base > > > > is > > > > renamed (that's exactly why we rename instead of force-push) -- no > > > > manual PR > > > > work. > > > > - The only manual step is for someone who keeps their fork's master in > > > > sync with > > > > upstream and wants to continue: rename their master to <repo>-4.x and > > > > track the > > > > new master. It's a one-time, documented step. > > > > > > > > And for the few who do keep a fork's master in sync with upstream, > > > > realigning is > > > > quick -- your current master (Maven 4) becomes upstream's <repo>-4.x, > > and > > > > master > > > > becomes Maven 3: > > > > > > > > git fetch upstream > > > > git branch -m master <repo>-4.x # your Maven 4 line > > > > git branch master upstream/master # the new Maven 3 default > > > > > > > > Open PRs move by themselves; the above is only for a long-lived local > > > > master, and > > > > it will be in the switch announcement too. > > > > > > > > On the benefit -- worth weighing honestly: it's not maintenance burden > > (the > > > > branches are the same either way), it's what a casual clone or a new > > > > contributor > > > > lands on. The agreed direction is Maven 3 as the default line until > > Maven 4 > > > > adoption has progressed; today a fresh clone of these repos lands on > > Maven > > > > 4, > > > > which is the opposite. > > > > > > > > Per repo, as "forks (created before the 4.x switch = Maven 3 master / > > > > created > > > > after = Maven 4 master / of those, active in the last 12 months)": > > > > > > > > - maven-compiler-plugin: 198 (156 / 42 / 26) > > > > - maven-jar-plugin: 80 (64 / 16 / 14) > > > > - maven-deploy-plugin: 79 (60 / 19 / 10) > > > > - maven-clean-plugin: 61 (46 / 15 / 8) > > > > - maven-install-plugin: 49 (39 / 10 / 6) > > > > - maven-source-plugin: 42 (27 / 15 / 10) > > > > - maven-filtering: 41 (26 / 15 / 11) > > > > - maven-resources-plugin: 39 (25 / 14 / 11) > > > > - maven-archiver: 30 (21 / 9 / 7) > > > > - Total: 619 (464 / 155 / 103) > > > > > > > > Only the last number on each line ("active Maven-4-master forks") is > > one > > > > that > > > > might want the one-time realign. > > > > > > > > > > > > > > > > > > > > > On 8. Oct 2026, at 09:30, Romain Manni-Bucau <[email protected]> > > > > wrote: > > > > > > > > > > Is the proposal to force all forks to be updated for both branches > > ([1])? > > > > > Is it worth it or do we expect your claude to go on all computers? > > > > > > > > > > [1] > > > > > > > > > > > https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch > > > > > > > > > > Romain Manni-Bucau > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > > > <https://dotnetbirdie.github.io/> | Blog < > > https://rmannibucau.github.io/> > > > > | Old > > > > > Blog <http://rmannibucau.wordpress.com> | Github > > > > > <https://github.com/rmannibucau> | LinkedIn > > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > > < > > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > > > Javaccino <https://javaccino.dev/> founder (Java/.NET service - > > contact > > > > via > > > > > linkedin) > > > > > > > > > > > > > > > Le jeu. 8 oct. 2026 à 09:26, Slawomir Jaranowski < > > [email protected]> > > > > a > > > > > écrit : > > > > > > > > > >> On Tue, 6 Oct 2026 at 10:46, Gerd Aschemann <[email protected]> > > wrote: > > > > >> > > > > >>> Hi all, > > > > >>> > > > > >>> Following up on Hervé's call to lead the Git work for > > maven-sources#57 > > > > < > > > > >>> https://github.com/apache/maven-sources/issues/57>: a handful of > > > > >>> Maven-4-specific plugins and shared components currently have their > > > > >> default > > > > >>> master branch on the Maven 4 line, with a <repo>-3.x branch for > > Maven > > > > 3. > > > > >>> That is the reverse of our agreed direction — the default should be > > > > Maven > > > > >>> 3, with Maven 4 as a separate branch until Maven 4 adoption has > > > > >> progressed. > > > > >>> Concretely, it avoids signalling that users moving to Maven 4.0 > > must > > > > also > > > > >>> switch to the new (Maven 4 API) plugins; Maven 4.0 is expected to > > run > > > > the > > > > >>> Maven 3 plugins. > > > > >>> > > > > >>> This originates from Hervé Boutemy (tracking issue + #maven Slack > > > > thread > > > > >> < > > > > >>> https://the-asf.slack.com/archives/C7Q9JB404/p1789896368528809>); > > the > > > > >>> full plan / runbook is on Confluence < > > > > >>> https://cwiki.apache.org/confluence/x/85fwGg>. > > > > >>> > > > > >>> Scope (plugins / components only, NOT Maven core): > > > > >>> > > > > >>> core plugins: clean, compiler, deploy, install, resources > > > > >>> packaging: jar, source > > > > >>> shared: archiver, filtering > > > > >>> special case: plugin-tools — no swap; master stays Maven 3 (drop > > the > > > > -3.x > > > > >>> branch, rename the version to 3.17.0-SNAPSHOT). > > > > >>> The target branch name stays master (not main); a move to main, if > > > > ever, > > > > >>> should be a separate global decision, not a side effect of this. > > > > >>> > > > > >>> Method — rename, not force-push: > > > > >>> > > > > >>> rename master (Maven 4) → <repo>-4.x > > > > >>> rename <repo>-3.x (Maven 3) → master > > > > >>> Renaming the base branch makes GitHub retarget open PRs > > automatically, > > > > so > > > > >>> merge bases and PR history are preserved (~45 open PRs across these > > > > >> repos). > > > > >>> > > > > >>> Impact on forks: renaming the upstream branches does not touch > > forks. A > > > > >>> fork's master keeps the old (Maven 4) content and its default > > branch is > > > > >>> unchanged; each fork owner realigns their own branches afterwards > > (e.g. > > > > >>> rename their master → <repo>-4.x and track the new upstream master > > = > > > > >> Maven > > > > >>> 3). Open PRs from forks keep working — GitHub retargets their base > > on > > > > the > > > > >>> upstream rename. This is a one-time, per-fork manual step; it will > > be > > > > >>> documented, and those of us with forks (myself included) will > > handle > > > > our > > > > >>> own as a follow-up. > > > > >>> > > > > >> > > > > >> Did we estimate how many forks will be affected by it? > > > > >> > > > > >> > > > > >>> > > > > >>> Plan: > > > > >>> > > > > >>> Execution approach agreed with INFRA: INFRA performs the two > > > > >>> protected-branch renames per repo by hand; we handle .asf.yaml, > > > > >> default.xml > > > > >>> and README. Rehearsed on a throwaway fork first. > > > > >>> One low-risk first test (maven-filtering, 1 open PR), verify, then > > the > > > > >>> rest en bloc — in a single coordinated window, timed with the > > plugin > > > > >>> maintainers and outside any open staging/release vote. > > > > >>> Timing: from ~16 October (after Community over Code). > > > > >>> Communication: to avoid noise I'll keep updates in this thread > > rather > > > > >> than > > > > >>> per-repo mails — a heads-up when we start with maven-filtering, > > and one > > > > >>> when starting the batch and when it is done. > > > > >>> > > > > >>> Please raise any objection — here or on maven-sources#57 < > > > > >>> https://github.com/apache/maven-sources/issues/57> — before we > > start > > > > >>> (targeting the weekend of 19 October, after the CoC@Glasgow). Feel > > > > free > > > > >>> to comment on Slack or Confluence as well. > > > > >>> > > > > >>> Thanks, Gerd > > > > >>> > > > > >>> -- > > > > >>> Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen > > > > >> Thomas) > > > > >>> +49/173/3264070 <+49%20173%203264070> <+49%20173%203264070> > > <+49%20173%203264070> > > > > <+49%20173%203264070> -- > > > > >> [email protected] -- > > > > >>> https://aschemann.net > > > > >>> > > > > >>> > > > > >> > > > > >> -- > > > > >> Sławomir Jaranowski > > > > >> > > > > > > > > -- > > > > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen > > Thomas) > > > > +49/173/3264070 <+49%20173%203264070> <+49%20173%203264070> -- > > [email protected] -- > > > > https://aschemann.net > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
