Bingo, i forgot that: Elliotte is mixing this one as well. I am still unsure what he talks about, but if he talks about Maven Central, all this discussion is futile.
On Wed, Jul 23, 2025, 16:12 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > > >
