I think this helps clarify what I actually mean by simplification.
My point is not mainly about reducing the number of characters, nor about
replacing XML with a DSL.
For example, I agree that this:
<dependency groupId="commons" artifactId="commons-lang" version="2.6"/>
is only a moderate improvement over the current form.
What I find more interesting is something like:
<dependency id="commons:commons-lang:2.6"/>
because here `id` has a semantic meaning.
`dependency` describes the kind of relationship, while `id` identifies
the artifact being referenced.
The remaining elements or attributes then describe the semantics of that
relationship, for example:
<dependency id="commons:commons-lang:2.6" scope="runtime"/>
or:
<dependency id="commons:commons-lang:2.6">
<exclusions>
<exclusion id="foo:bar"/>
</exclusions>
</dependency>
So for me the interesting part is not really "how many characters can we
save?", but whether Maven repeatedly expresses the same concept —
artifact identity — through separate groupId/artifactId/version fields.
This also seems to generalize naturally to other elements:
<plugin id="org.apache.maven.plugins:maven-compiler-plugin:3.14.0"/>
<exclusion id="foo:bar"/>
<mixin id="com.example:java-mixin:1.0.0"/>
In that sense, IDE folding can certainly solve the visual-density problem,
but it does not answer the modeling question.
So I think my preference would be:
keep XML static and declarative,
keep structured configuration for complex cases,
but give artifact references a compact identity where that identity
is already a natural concept in the model.
Regards,
Billy
On Tue, Aug 18, 2026 at 12:16 AM Romain Manni-Bucau <[email protected]>
wrote:
> thinking out loud: is it a real issue? point is that several IDE already do
> collapse and "render" (until opened) it inlined so maybe more a tooling
> thing.
>
> At the end
>
>
> <dependency><groupId>commons</groupId><artifactId>commons-lang</artifactId><version>2.6</version></dependency>
>
> vs
>
> <dependency groupId="commons" artifactId="commons-lang" "version="2.6" />
>
> is not a real win in terms of verbosity IMHO
>
> and ultimately
>
> <dependency groupId="commons:commons-lang:2.6" />
>
> is a lost in terms of grammar
>
> so maybe we just fight at the wrong level there, in particular when
> dependencies are often "copied" (docs) or "injected' (LLM) and more rarely
> written manually these days
>
> 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 lun. 17 août 2026 à 04:18, Josh Biily <[email protected]> a
> écrit :
>
> > I actually agree that Maven's static descriptor is a strength.
> > My interest in simplification is not about replacing XML with a DSL. I
> used
> > Gradle before and eventually moved back to Maven, partly because the
> faster
> > evolution and compatibility between Gradle, IDE and JDK versions created
> > more maintenance cost for me.
> > What I am more interested in is keeping Maven declarative and static,
> while
> > making common declarations fit into one or two lines where possible.
> >
> > On Fri, Aug 14, 2026 at 11:41 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]
> > > > >
> > > > >
> > > >
> > >
> >
>
