Re: [DISCUSS] Should Maven 4 prioritize forward evolution over full Maven 3 compatibility?
Josh Biily <[email protected]>
| Newsgroups | gmane.comp.jakarta.turbine.maven.devel |
|---|---|
| Message-ID | <CA+8Mx_wVQKcmZg=e0iXa-evfEM86duNfHVf2L4jsyghwC-Bpfw@mail.gmail.com> |
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]
>
>