This sounds very promising. Thank you for the detailed response! It seems that one mistake that I had is to use maven 3 plugins (as all the versions are explicitly defined to have reproducible builds) instead of the new RC versions for all the plugins when checking Maven 4. Also, the -bconcurrent is something I was really not aware of, so I will check it as well.
On Sun, Aug 23, 2026 at 11:38 PM Guillaume Nodet <[email protected]> wrote: > 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 >
