Thanks for this detailed write-up — the problem analysis is spot-on and the
results with the turbo-builder are impressive. You're right that the
original sequential contract is the root bottleneck on modern hardware.
*The good news: Maven 4's concurrent builder addresses the core insight
architecturally.*
The work done under MNG-8052 and MNG-8225 redesigned the lifecycle from a
flat, sequential phase list into a hierarchical dependency tree:
ALL
└── EACH (per-module)
├── VALIDATE
│ └── INITIALIZE
├── BUILD (after VALIDATE)
│ ├── SOURCES / RESOURCES (parallel — no mutual dependency)
│ ├── COMPILE (after SOURCES; upstream deps at READY)
│ ├── READY (after COMPILE + RESOURCES)
│ └── PACKAGE (after READY; upstream deps at PACKAGE)
├── VERIFY (after VALIDATE) ← sibling of BUILD, not sequenced after it
│ ├── UNIT_TEST (TEST_COMPILE depends on READY)
│ └── INTEGRATION_TEST
├── INSTALL (after PACKAGE)
└── DEPLOY (after PACKAGE)
The critical design point: *BUILD and VERIFY both depend on *after(VALIDATE)*
but not on each other.* This means the BuildPlanExecutor can schedule them
concurrently — which is exactly the insight your turbo-builder exploits,
but expressed as a first-class dependency constraint rather than a phase
reordering hack.
Specifically, the two optimizations you describe map directly:
1. *"Schedule downstream dependencies after package, not after all phases"*
→ In Maven 4, inter-module dependencies declare which phase they need
(e.g., compile-scoped deps need upstream at READY, runtime-scoped at PACKAGE).
A downstream module's COMPILE can start as soon as its upstream reaches
READY — it doesn't wait for the upstream's tests, integration-tests, or
deploy.
2. *"Run tests after package"* → In Maven 4, UNIT_TEST lives under VERIFY,
which is a sibling of BUILD, not a child of it. Tests are not sequenced
before PACKAGE; TEST_COMPILE merely depends on READY (main compilation
done). So the scheduler is free to run tests and packaging concurrently or
in either order.
You enable this with mvn --builder=concurrent -T ....
*Where I still see gaps:*
1. *Real-world performance validation on large reactors.* You mentioned
early experiments with Maven 4 showed degrading performance — "logs printed
slower and slower" with no obvious heap/thread leak. This was discussed on
the dev list thread and is the most critical gap. The architecture is
sound, but if there's a performance regression in the execution engine
itself (classloader contention, plugin isolation overhead, scheduling
granularity), the theoretical gains won't materialize. For a 1100+ module
project, this needs dedicated profiling. I'd encourage filing specific
performance reports with timeline data (e.g., from maven-bench) against the
latest RC so the issue can be isolated.
2. *Plugin compatibility surface area.* The concurrent builder warns about
non-Maven-4-aware mojos (similar to how -T warns about non-thread-safe
mojos in Maven 3). For a project with 1100+ modules, the plugin ecosystem
friction is real — any mojo that assumes sequential phase execution or
writes to shared state will break. The test-jar packaging issue you
mentioned is one example. The ecosystem needs time to catch up, and there's
no registry of "concurrent-safe" plugins yet.
3. *Build caching interaction.* You mention the turbo-builder works with
caching solutions (including the Apache Build Cache Extension). The
concurrent builder's finer-grained scheduling changes the invalidation
surface — a phase that ran concurrently with something it previously ran
after might produce different cache keys. This interaction needs explicit
testing and documentation.
4. *Diagnostic tooling.* Understanding *why* a concurrent build is slow
requires timeline visualization of phase execution across modules — which
threads ran what, where the idle gaps are, which dependency constraints
forced waits. Tools like takari-timeline addressed this for Maven 3's
module-level parallelism, but Maven 4's phase-level granularity needs
equivalent tooling. Without it, large projects can't diagnose whether
they're hitting a scheduling bottleneck, a plugin bottleneck, or an engine
bottleneck.
5. *Opt-in vs. default.* The concurrent builder is disabled by default. For
the ecosystem to evolve, it probably needs to become the default in a
future Maven version (5?) — which requires the plugin compatibility story
to be solid first. Until then, adoption will remain limited to projects
willing to take the risk.
*Bottom line:* I think Maven 4's concurrent builder is the right
architectural answer to the problem your turbo-builder solved
pragmatically. The lifecycle tree with after() constraints is strictly more
expressive than phase reordering — it can model everything the
turbo-builder does and more. The remaining question is whether the
*implementation* delivers the performance in practice, especially on very
large reactors. The best way to drive that forward is filing concrete
performance data against the latest Maven 4 RCs and working with the Maven
team to profile the gaps. Your 1100+ module project would be a fantastic
real-world stress test....
Guillaume
Le sam. 15 août 2026 à 21:52, Sergey Chernov <[email protected]> a
écrit :
> One more thing I'd like to mention in the context of Maven 4.1/5 and back
> compatibility vs evolution.
>
> *Small preamble*
> Originally, Maven was created for single-core machines, it built
> multi-module projects sequentially according to their dependency tree.
> Later, in Maven 3, the multi-threaded builder
> <https://maven.apache.org/ref/3.5.0/apidocs/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.html>
> was added (it's used when the -T parameter is specifying the number of
> working threads).
> This works fine, but inherits the original contract from the old maven: in
> the multi-module build any downstream dependency is built when ALL phases
> of the upstream are complete, not earlier.
> In other words, if moduleB has a dependency to moduleA (any scope), maven
> will build all phases of moduleA (say, from clean to verify), and only then
> start building moduleB.
> This significantly reduces possible parallelism of the build. If you
> compare this to other build tools, e.g. Gradle (which was created when we
> had multi-core CPUs already), it arranges it in a pretty different way: the
> build graph is way more granular and contains tasks, not whole modules like
> gradle. As a result, in the multi-core systems it utilizes working threads
> way more efficiently.
> In other words, it uses optimistic strategy instead of pessimistic in
> Maven - in Gradle we do not wait for tests of moduleA, and can start
> building moduleB right after moduleA sources are compiled.
>
> I was thinking a lot on this problem, analyzed timelines of the build and
> eventually created my own builder, which some of you already know
> https://github.com/maven-turbo-reactor/maven-turbo-builder
> It does two things:
> * run tests after package, not before as it's defined in the standard
> lifecycle
> * schedule downstream dependencies right after the package phase of the
> upstream dependency, not waiting for test, integration-test, verify,
> install, etc.
>
> [image: image.png]
>
> [image: image.png]
>
> As a result, it shifts left the build in the timeline, the overall build
> time is approx ~30% faster, and you need smaller number of working threads
> (we use -T0.5C for mac on Apple Silicon chips), smaller amount of memory
> needed (!) because of the lower number of working threads.
>
> For sure, it has some limitations and compatibility problems, e.g.
> test-jar packaging needs special exclusions here, also some specific
> plugins can be broken which rely on the standard contract.
>
> But the benefit of the faster build is so significant, that I don't see
> any other way at least for our project.
> Worth to mention, it works in combination with build caching solutions
> (and not only with Apache Build Cache Extension). And in many scenarios it
> can be way more efficient than Gradle build of the equivalent module
> structure and build logic.
>
> *Proposal*
> Ideally, I'd like to see the evolution of Maven in this direction. Java is
> getting faster and faster with each Major release. Other huge projects like
> Spring invest a lot to optimize the build performance. IMO maven should bet
> on build performance as well. And if we need to eventually break the back
> compatibility there, at least this should be planned.
> Maven 4 has a lot of nice features, but it seems we'll either stay on
> Maven 3 (+with own extensions), or switch to another build tool, as build
> performance is crucial for our huge project (1100+ modules).
>
> This change will break some scenarios, but I see a few steps there.
>
> First - change the order of package and test. Later this unblocks the
> second one.
> Second - split single list of goals that are executed sequentially in
> DefaultMojosExecutionStrategy
> <https://maven.apache.org/ref/4.0.0-alpha-2/xref/org/apache/maven/plugin/DefaultMojosExecutionStrategy.html>
> to parts. In my extension these are two parts (clean..package, and
> test-compile,test..deploy), it can be different, e.g. I see in Maven 4
> already sub-lifecycles VALIDATE, BUILD, VERIFY, INSTALL, DEPLOY
> (see DefaultLifecycleRegistry.DefaultLifecycle.phases).
>
> When we are talking about build performance, I often hear "use build
> cache". Don't be confused: build cache optimizes the best case when you
> have the entry (in real projects the hit rate can be quite low), but you
> also need to invest to efficiently build the worst case as well, so on
> average it's faster.
>
>
> On Fri, Aug 14, 2026 at 5:42 PM Romain Manni-Bucau <[email protected]>
> wrote:
>
>> Small note: one strength of maven descriptor is to be static, ie it can be
>> loaded whatever tooling you do use independently of the validity of the
>> env
>> (parsing an XML today), I strongly think it is a killer feature compared
>> to
>> gradle (which totally messes up the IDE if the build script can't be
>> loaded/compiled cause of a broken java version or dependency/repository
>> setup). Means XML, JSON(5), TOML etc are options, groovy/ruby/python are
>> not for example - as a standard feature, as a polyglot extension it always
>> had been.
>> Also means the verbosity is not much an issue since enclosed in tooling -
>> worse with LLM BTW, so even if I like the inline syntax I'm not that
>> convinced it is a high priority or a game changer.
>>
>> 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. 14 août 2026 à 11:49, Josh Biily <[email protected]> a
>> écrit :
>>
>> > Hi all,
>> >
>> > Following up on the suggestion to consolidate the historical POM/GAV
>> > simplification proposals, I spent some time going through the related
>> > issues.
>> >
>> > My original motivation was very simple: dependency lists take a lot of
>> > vertical space, and I wanted to see more useful information on one
>> > screen.
>> >
>> > After reading the historical discussions, however, I realized that the
>> > community has explored this topic much more deeply than simply "making
>> > XML shorter".
>> >
>> > I found it more useful to group the proposals by goal first, and use
>> > chronology inside each group.
>> >
>> > This is only a first pass. I am not trying to recommend a particular
>> > syntax here, but rather to collect previous thinking and understand how
>> > the design space has evolved.
>> >
>> >
>> > 1. Reduce XML verbosity while keeping XML
>> > ------------------------------------------
>> >
>> > One long-running direction was to retain the existing POM structure
>> > while representing simple values more compactly.
>> >
>> > MNG-3397 / #5479 dates back to 2008 and broadly proposed using XML
>> > attributes in the POM.
>> >
>> > Related proposals include:
>> >
>> > 2009 MNG-4090 Allow attribute based configuration
>> > 2012 MNG-5392 Support XML attributes for simple data types in POM
>> > 2014 MNG-5653 POM using attributes for plugin definitions
>> > 2016 MNG-5996 A cleaner approach to defining dependencies
>> >
>> > A typical proposal was:
>> >
>> > <dependency groupId="org.example" artifactId="example-api"
>> > version="1.0.0"/>
>> >
>> > instead of:
>> >
>> > <dependency>
>> > <groupId>org.example</groupId>
>> > <artifactId>example-api</artifactId>
>> > <version>1.0.0</version>
>> > </dependency>
>> >
>> > The motivations were not only fewer characters. The discussions mention
>> > information density, less cursor movement, easier scanning, and making
>> > dependency lists easier to understand.
>> >
>> > The plugin proposal also contained forms such as:
>> >
>> > <plugin id="maven-compiler-plugin:3.1"/>
>> >
>> > which already suggests another recurring design idea:
>> >
>> > identity -> compact
>> > configuration -> structured
>> >
>> >
>> > 2. Give Maven artifacts a compact identity
>> > -------------------------------------------
>> >
>> > Later proposals went beyond moving XML elements into attributes and
>> > asked whether Maven coordinates themselves should have a compact
>> > representation.
>> >
>> > MNG-7005 / #8030 proposed a Gradle-style form:
>> >
>> > <gav>groupId:artifactId:version</gav>
>> >
>> > MNG-7039 / #7998 explored a URI-like coordinate:
>> >
>> > <dependency
>> > uri="mvn:com.company/foo-api/1.0.1-SNAPSHOT"
>> > scope="compile"/>
>> >
>> > That proposal was interesting because its motivation was broader than
>> > POM readability: an official single-string Maven coordinate could also
>> > be useful for artifact identification and automation.
>> >
>> > More recently, #11500 revisited the problem. Its initial proposal was
>> > roughly:
>> >
>> > <dependency>groupId:artifactId:version</dependency>
>> >
>> > The discussion subsequently moved toward:
>> >
>> > <dependency id="groupId:artifactId:version">
>> > ...
>> > </dependency>
>> >
>> > This has now resulted in PR #11904, which proposes compact id forms for
>> > Dependency, Exclusion and Mixin, for example:
>> >
>> > <dependency id="org.slf4j:slf4j-api:2.0.17"/>
>> >
>> > <dependency id="org.postgresql:postgresql:42.7.3">
>> > <exclusions>
>> > <exclusion id="*:*"/>
>> > </exclusions>
>> > </dependency>
>> >
>> > <mixin id="com.example.mixins:java-mixin:1.0.0"/>
>> >
>> > As of now, that PR is still open and targeted at the 4.1.0 milestone.
>> >
>> > Looking across these proposals, there appears to be a recurring
>> > principle:
>> >
>> > identity -> compact
>> > configuration -> structured
>> >
>> > Whether id is ultimately the preferred syntax is a separate question,
>> > but the principle seems to recur across proposals separated by many
>> > years.
>> >
>> >
>> > 3. Make the authoring format itself replaceable
>> > ------------------------------------------------
>> >
>> > MNG-6061 took a different approach.
>> >
>> > Instead of asking how XML could be made shorter, it asked whether Maven
>> > configuration could use alternative formats such as YAML or TOML.
>> >
>> > That changes the question from:
>> >
>> > How can XML be less verbose?
>> >
>> > to:
>> >
>> > Does the build authoring format need to be XML?
>> >
>> > Historically, this was difficult because Maven's model and its XML
>> > representation were tightly connected.
>> >
>> > The Maven 4 architecture changes the context considerably. ModelParser
>> > provides an SPI for additional model syntaxes, while the Build POM /
>> > Consumer POM distinction allows build-time authoring information to
>> > differ from the POM consumed by downstream tools.
>> >
>> > This makes alternative authoring syntax more technically feasible,
>> > although the ecosystem question remains: multiple equivalent formats
>> > also increase tooling, documentation, debugging and cognitive costs.
>> >
>> >
>> > 4. Simplify the model structure itself
>> > ---------------------------------------
>> >
>> > MNG-6230, opened in 2017 and still open, addresses a different kind of
>> > complexity.
>> >
>> > Its proposal explores separating plugin identity from execution
>> > declarations.
>> >
>> > Conceptually:
>> >
>> > plugin definition:
>> > what tool is being used?
>> >
>> > execution definition:
>> > when and how should it run?
>> >
>> > This seems important because not all POM complexity is syntactic.
>> >
>> > A POM can be concise while the underlying model is still difficult to
>> > reason about.
>> >
>> > So it may be useful to distinguish:
>> >
>> > syntactic complexity
>> > from
>> > structural/model complexity
>> >
>> >
>> > What seems to recur
>> > -------------------
>> >
>> > From this first pass, I see four recurring goals:
>> >
>> > 1. Reduce XML verbosity
>> > 2. Compact or standardize artifact identity
>> > 3. Allow alternative authoring syntax
>> > 4. Simplify POM model/structure
>> >
>> > Within the first two areas, there is also an interesting historical
>> > progression:
>> >
>> > child XML elements
>> > ->
>> > XML attributes
>> > ->
>> > compact GAV
>> > ->
>> > canonical-coordinate ideas
>> > ->
>> > id="g:a:v" with structured configuration around it
>> >
>> > The motivations raised over the years include much more than typing
>> > less: readability, information density, artifact identity, automation,
>> > backward compatibility, parser/model constraints, tooling consistency
>> > and separation of concerns.
>> >
>> > The objections also seem to fall into two different groups.
>> >
>> > Some were historical technical constraints, for example limitations in
>> > Maven's model or parser architecture.
>> >
>> > Others are still design questions even if implementation is easier
>> > today, for example whether introducing multiple equivalent syntaxes
>> > increases ecosystem complexity more than it improves authoring.
>> >
>> > That distinction seems particularly relevant when revisiting these
>> > ideas in the Maven 4.x / 4.1 context.
>> >
>> > I am sure this consolidation is incomplete. Older discussions are
>> > distributed across JIRA, GitHub, mailing lists, Wiki pages and
>> > experiments outside Maven core.
>> >
>> > If anyone remembers important proposals that are missing, or if I have
>> > misunderstood the intent or outcome of any of the items above,
>> > corrections and additions would be very welcome.
>> >
>> > Regards,
>> > Billy
>> >
>> > On Fri, Aug 14, 2026 at 4:08 PM Hervé Boutemy <[email protected]>
>> wrote:
>> >
>> > > just landed :)
>> > >
>> > > happy that 4.0 vs 4.1 clarifies things:
>> > > in fact, what we currently have in 4.1 is what I called Maven 5 in
>> 2021
>> > > https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
>> > >
>> > > there is one key feature that initially should have waited for 4.1/5
>> but
>> > > is in 4.0 to prepare all the plugins alongside: this is Java Module
>> > native
>> > > build (because this is strategic and we have great experts giving a
>> lot
>> > of
>> > > efforts, experrience and time for it)
>> > > =
>> > >
>> >
>> https://cwiki.apache.org/confluence/spaces/MAVEN/pages/393677487/Full+Java+Modules+Support+-+Current+State
>> > >
>> > >
>> > > we have so many proposals about gav XML simplification that just
>> > > consolidating all good ideas that were written in the past will be a
>> big
>> > > task (search in GH issues, in Wiki, and in a lot of places)
>> > > whoever has the energy to start that consolidation is welcome
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > On 2026/08/14 06:15:49 Josh Biily wrote:
>> > > > Hi Hervé,
>> > > >
>> > > > Thank you for the detailed explanation. This makes the current Maven
>> > 4.0
>> > > > strategy much clearer to me.
>> > > >
>> > > > I especially like the distinction between "reasonable compatibility"
>> > and
>> > > > perfect compatibility. Supporting existing Maven 3 plugins enough to
>> > let
>> > > > users cross the bridge first, and then allowing Maven 4.1+ to move
>> more
>> > > > aggressively forward, sounds like a very practical approach.
>> > > >
>> > > > Your "cut the bridge behind us, not in front of us" analogy explains
>> > the
>> > > > strategy very well.
>> > > >
>> > > > I am also glad to hear that GAV/XML simplification is already being
>> > > > discussed internally. For everyday users, improvements like that are
>> > > highly
>> > > > visible and can make Maven 4 feel like a real new generation, not
>> only
>> > an
>> > > > internal architectural upgrade.
>> > > >
>> > > > I will keep an eye on RC7 and the 4.1 work. Thanks again for taking
>> the
>> > > > time to explain the plan.
>> > > >
>> > > > Best regards,
>> > > > Josh
>> > > >
>> > > > On Fri, Aug 14, 2026 at 12:39 PM Hervé Boutemy <[email protected]
>> >
>> > > wrote:
>> > > >
>> > > > > I forgot to add a few key links:
>> > > > >
>> > > > > - we have the first layer of syntactic sugar in place in 4.0, to
>> > > prepare
>> > > > > the next ones you are asking for (that would not be reasonable
>> for a
>> > > first
>> > > > > step):
>> > > > > see https://maven.apache.org/whatsnewinmaven4.html
>> > > > >
>> > > > > - we have the compatibility tests and users migration process:
>> > > > > see
>> > https://maven.apache.org/guides/mini/guide-migration-to-mvn4.html
>> > > > >
>> > > > > - we have the first strong improvement in Maven 4.1 already
>> > documented
>> > > =
>> > > > > mixins, just don't talk much about it because we need to focus on
>> 4.0
>> > > > > before 4.1:
>> > > > > see https://maven.apache.org/guides/mini/guide-mixins.html
>> > > > >
>> > > > >
>> > > > > your feedback proves me that the hard discussion about the gav XML
>> > > pattern
>> > > > > simplification should probably be our next key hot discussion...
>> > > > > we have people ready for that, we just asked them to ait a little
>> bit
>> > > for
>> > > > > now...
>> > > > >
>> > > > >
>> > > > > On 2026/08/14 04:28:27 Hervé Boutemy wrote:
>> > > > > > very good question
>> > > > > >
>> > > > > > the key topic is the huge community-provided Maven plugins: we
>> > cannot
>> > > > > just ignore them, this would be detrimental to both maintainers
>> and
>> > > users
>> > > > > > = force new Maven 4 users to wait for every plugin maintainer to
>> > > create
>> > > > > a new Maven 4 plugin
>> > > > > >
>> > > > > > that's why we have a *reasonable* Maven 3 plugins in Maven 4
>> plan.
>> > > > > > here, *reasonable* is key: not for Maven 3 plugins that use
>> Maven 2
>> > > > > compatibility layer = no, that one would be too much
>> > > > > >
>> > > > > >
>> > > > > > We communicate a lot on this compatibilty aspect for Maven 4.0,
>> and
>> > > > > smooth transition to the new POM model, because it's a key scope
>> for
>> > a
>> > > > > first wave of safe usage and transition for everybody
>> > > > > >
>> > > > > > but don't worry: Maven 4.1 is in progress in parallel, with
>> more of
>> > > what
>> > > > > you are implicitely asking for and that we are also willing. We
>> just
>> > > had to
>> > > > > clarify our Maven 4.0 focus first.
>> > > > > >
>> > > > > > Maven 4.0 will be out soon with that "good" (not perfect,
>> > perfection
>> > > > > cannot be a reasonable objective) compatibility for safe
>> transition
>> > > > > >
>> > > > > > then we can safely focus on 4.1 and more aggressive "forget
>> Maven
>> > 3"
>> > > > > plan: we have the first step in place now to be able to cut the
>> > bridge
>> > > > > behind us, not in front of us :)
>> > > > > >
>> > > > > >
>> > > > > > We can go more in tech details, but this is the plan that is
>> > > currently
>> > > > > landing with good confidence: time between RC5 and 6 was too long,
>> > > we're
>> > > > > now ready for a quick RC 7 and 4.0.0 very soon
>> > > > > >
>> > > > > > Plugin maintainers, users: please help us testing with 4.0 RC6
>> and
>> > > 4.0
>> > > > > RC7, as this is the last call before 4.0 (I'm currently in an
>> > airport,
>> > > this
>> > > > > is the last call for my flight :) )
>> > > > > >
>> > > > > > Hope this clarifies your good concerns
>> > > > > >
>> > > > > > Hervé
>> > > > > >
>> > > > > > On 2026/08/14 02:27:07 Josh Biily wrote:
>> > > > > > > Hello Maven developers,
>> > > > > > >
>> > > > > > > English is not my native language, so I hope you can
>> understand
>> > if
>> > > some
>> > > > > > > wording is not perfectly precise.
>> > > > > > >
>> > > > > > > I would like to raise a design and release-strategy question
>> > about
>> > > > > Maven 4.
>> > > > > > >
>> > > > > > > This is not intended as a complaint about Maven 4 development
>> > > speed or
>> > > > > the
>> > > > > > > work already invested in compatibility. Maven is critical
>> > > > > infrastructure
>> > > > > > > for the Java ecosystem, and I understand why backward
>> > compatibility
>> > > > > matters.
>> > > > > > >
>> > > > > > > My question is whether Maven 4 may be carrying too much
>> > > compatibility
>> > > > > > > responsibility for Maven 3.
>> > > > > > >
>> > > > > > > My main thought is:
>> > > > > > >
>> > > > > > > Maven 3 can continue to serve existing and legacy projects,
>> while
>> > > > > Maven 4
>> > > > > > > can focus more aggressively on new projects and the future
>> Java
>> > > > > ecosystem.
>> > > > > > >
>> > > > > > > We already accept this model elsewhere.
>> > > > > > >
>> > > > > > > Many companies still run Java 8 applications today. Those
>> > projects
>> > > may
>> > > > > > > remain on Java 8 for years because stability is more important
>> > than
>> > > > > > > upgrading. That does not prevent Java 17, 21, or 25 from
>> moving
>> > > > > forward.
>> > > > > > >
>> > > > > > > Spring Boot is another example. Many production systems still
>> use
>> > > > > Spring
>> > > > > > > Boot 2.x, while Spring Boot 3 moved to Java 17 and Jakarta EE
>> > with
>> > > > > > > significant breaking changes. Existing Boot 2 applications did
>> > not
>> > > > > need to
>> > > > > > > migrate immediately, but their existence did not prevent newer
>> > > > > generations
>> > > > > > > from evolving.
>> > > > > > >
>> > > > > > > Python 2 and Python 3 provide a stronger example. Old Python 2
>> > > > > applications
>> > > > > > > could remain on Python 2 while Python 3 continued to evolve.
>> > > Migration
>> > > > > was
>> > > > > > > optional and happened when the benefits justified the cost.
>> > > > > > >
>> > > > > > > I wonder whether Maven could follow a similar model:
>> > > > > > >
>> > > > > > > -
>> > > > > > >
>> > > > > > > Maven 3 remains a stable maintenance line for legacy
>> projects.
>> > > > > > > -
>> > > > > > >
>> > > > > > > Existing Java 8/11 projects and old plugin ecosystems can
>> > > continue
>> > > > > using
>> > > > > > > Maven 3.
>> > > > > > > -
>> > > > > > >
>> > > > > > > Maven 4 primarily targets modern Java projects, for example
>> > Java
>> > > > > 17+.
>> > > > > > > -
>> > > > > > >
>> > > > > > > Maven 4 may introduce carefully chosen breaking changes
>> when
>> > > they
>> > > > > > > provide substantial improvements in architecture, APIs,
>> > > performance,
>> > > > > > > maintainability, or developer experience.
>> > > > > > > -
>> > > > > > >
>> > > > > > > Projects that do not need Maven 4 are not required to
>> migrate.
>> > > > > > > -
>> > > > > > >
>> > > > > > > Projects that want Maven 4 can migrate when the benefits
>> > > justify it.
>> > > > > > >
>> > > > > > > In other words, backward compatibility would still be
>> important,
>> > > but
>> > > > > > > perhaps it could be treated partly as a migration problem
>> rather
>> > > than
>> > > > > as a
>> > > > > > > requirement that every Maven 3 project and historical behavior
>> > work
>> > > > > > > unchanged under Maven 4.
>> > > > > > >
>> > > > > > > A compatibility checker or migration tool might sometimes
>> provide
>> > > more
>> > > > > > > value than perfect compatibility. For example, a future tool
>> > could
>> > > > > report:
>> > > > > > >
>> > > > > > > -
>> > > > > > >
>> > > > > > > incompatible plugins
>> > > > > > > -
>> > > > > > >
>> > > > > > > deprecated or removed APIs
>> > > > > > > -
>> > > > > > >
>> > > > > > > unsupported POM behaviors
>> > > > > > > -
>> > > > > > >
>> > > > > > > model differences
>> > > > > > > -
>> > > > > > >
>> > > > > > > required migration steps
>> > > > > > >
>> > > > > > > The practical reason I think this distinction matters is that
>> the
>> > > > > projects
>> > > > > > > most dependent on old Maven behavior are often also the least
>> > > likely to
>> > > > > > > upgrade Maven.
>> > > > > > >
>> > > > > > > A stable Java 8 application with old plugins and a mature
>> build
>> > > > > pipeline
>> > > > > > > may intentionally remain unchanged for many years. Ensuring
>> that
>> > > such a
>> > > > > > > project can use Maven 4 without modification may require
>> > > substantial
>> > > > > > > engineering effort, even though its maintainers may never
>> plan to
>> > > move
>> > > > > to
>> > > > > > > Maven 4.
>> > > > > > >
>> > > > > > > Meanwhile, new Java 21 or Java 25 projects are more likely to
>> > adopt
>> > > > > Maven 4
>> > > > > > > and may benefit from improvements that are difficult to
>> introduce
>> > > under
>> > > > > > > very strict Maven 3 compatibility constraints.
>> > > > > > >
>> > > > > > > So perhaps the two goals could be separated more explicitly:
>> > > > > > >
>> > > > > > > Maven 3 prioritizes stability and compatibility.
>> > > > > > >
>> > > > > > > Maven 4 prioritizes forward evolution.
>> > > > > > >
>> > > > > > > These goals do not necessarily conflict. A stable Maven 3 line
>> > > gives
>> > > > > > > existing users a safe place to remain, and that stability may
>> > > actually
>> > > > > give
>> > > > > > > Maven 4 more freedom to evolve.
>> > > > > > >
>> > > > > > > I also think this could help Maven 4 provide more visible
>> > benefits
>> > > to
>> > > > > > > everyday users.
>> > > > > > >
>> > > > > > > For example, common dependency declarations are still verbose:
>> > > > > > >
>> > > > > > > <dependency>
>> > > > > > > <groupId>org.apache.commons</groupId>
>> > > > > > > <artifactId>commons-lang3</artifactId>
>> > > > > > > <version>3.18.0</version>
>> > > > > > > </dependency>
>> > > > > > >
>> > > > > > > For common cases, a future POM model could theoretically
>> support
>> > > > > syntactic
>> > > > > > > sugar such as:
>> > > > > > >
>> > > > > > > <gav>org.apache.commons:commons-lang3:3.18.0</gav>
>> > > > > > >
>> > > > > > > while keeping the traditional <dependency> form for complex
>> > cases.
>> > > > > > >
>> > > > > > > This is only an example, not the main proposal. My broader
>> point
>> > is
>> > > > > that a
>> > > > > > > major version should ideally have enough user-visible
>> > improvements
>> > > to
>> > > > > give
>> > > > > > > developers a reason to adopt it, even if some improvements
>> > require
>> > > > > > > carefully documented incompatibilities.
>> > > > > > >
>> > > > > > > I am not suggesting that Maven 4 should break compatibility
>> > > casually.
>> > > > > > >
>> > > > > > > I am suggesting that compatibility may benefit from having a
>> > > > > cost-benefit
>> > > > > > > threshold. If preserving a Maven 3 behavior significantly
>> delays
>> > > Maven
>> > > > > 4,
>> > > > > > > complicates its architecture, or prevents meaningful
>> improvements
>> > > for
>> > > > > > > modern projects, documenting the incompatibility and
>> providing a
>> > > > > migration
>> > > > > > > path may sometimes be the better trade-off.
>> > > > > > >
>> > > > > > > Would the Maven team consider formally treating Maven 3 as the
>> > > > > long-term
>> > > > > > > stability/compatibility line, while allowing Maven 4 more
>> freedom
>> > > for
>> > > > > > > carefully chosen breaking changes aimed at modern Java
>> projects?
>> > > > > > >
>> > > > > > > I would be interested to hear how the Maven team currently
>> thinks
>> > > about
>> > > > > > > this trade-off.
>> > > > > > >
>> > > > > > > Thank you for your work on Maven.
>> > > > > > >
>> > > > > >
>> > > > > >
>> > ---------------------------------------------------------------------
>> > > > > > 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
