I'm not sure I grasp all the discussion so maybe i'll say something off but for me deployment model should stay 4.0.0 for that exact reason (we have too much consumer out there and if we are moving namespaces at need it will break too often IMHO). For the build itself I'm tempted to move to whatever fits maven when needed so 5.0.0 it ok now while we still publish 4.0.0.
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> Le mer. 23 juil. 2025 à 15:38, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > On Wed, Jul 23, 2025 at 1:07 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > To me your message sounds you assume model parsing == model building. > > Dependency trees and XML parsing? Analyzing what is in project? Just as > > users can use xpath or other standard tech? > > > > This is totally unrelated and POMs alone are most often even incomplete > as > > they have parents, imports and interpolation and profile activations and > so > > on. > > > > This is an important point. The Maven repository system is more than > Maven. The pom.xml is not just for Maven. Most obviously it is also > used by gradle, Ivy, bazel, and other build tools. POMs are also > consumed by static analyzers who want to figure out what dependency > trees look like, most commonly whether there are vulnerable or banned > dependencies but also for things like dependency convergence and > necessary updates. There are others, and there would be many more if > the pom format were easier to consume and process. > > At one point a large part of my day job was writing software to > analyze and understand the dependency graph of various projects. We > ended up spending probably several hundred thousand dollars worth of > engineer time because we couldn't use standard XML tools for this task > precisely due to the namespace problems. Google could afford to work > around that, but a lot of organizations can't. > > I wish the repository system and pom format were not so tightly > coupled to the Maven build tool, but that ship sailed long ago. > Ideally the decision about when and whether to revise the pom.xml > format would not be made not only by Apache Maven developers but > instead include all the stakeholders: Gradle, Sonatype, Google, > Oracle, and more. So far none of them have been heard from. We just > have a very small group of active developers of one build tool making > decisions for everyone. What we can do now is avoid making the problem > even worse by introducing additional namespace URIs beyond what we > already have. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
