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] > > > > >
