I don't get what you're saying Romain. I think building a project from sources without using Maven is a bad idea, it kinda means reinventing maven. Processing the build POM without relying on Maven libraries is also a bad idea for the same reason. Even reading the consumer POM and rebuilding the dependency tree without Maven is a bad idea.
We need to make maven versatile enough to allow those usages. It has already improved a lot with the new API which can already be used outside the Maven runtime to build effective model, resolve dependencies, etc.. Guillaume Le jeu. 24 juil. 2025 à 16:43, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > No, when building you have the consumer pom locally too and anyway if we > say this is an issue we just revert everything and stay on 4.0.0 which is > very unlikely for all the reason we are discussing maven 4 so not sure we > have the choice to be frank. > > 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 jeu. 24 juil. 2025 à 16:38, Sylwester Lachiewicz <slachiew...@gmail.com > > > a écrit : > > > If I understand correctly - consumer pom is for consumers that accept > > binary artefacts. So do security reasons, if someone decides to build it > > internally from sources - this will not work and still needs to accept > > different build pom styles. > > We are aiming for build reproducibility anyway. > > > > Sylwester > > > > czw., 24 lip 2025, 16:12 użytkownik Romain Manni-Bucau < > > rmannibu...@gmail.com> napisał: > > > > > Not sure it changes anything, you can still build from source, get the > > > consumer pom and parse it. > > > What we should encourage for sure is to NOT do it for build pom within > > the > > > project since now we can change it anytime for new features (hopefully > > not > > > too often but we enabled it cause it was an issue). > > > Also enables projects to use whatever language/syntax they want. > > > So the only pivot format you have is the consumer pom and it doesn't > > > require a remote repository so all good for everybody I think. > > > > > > 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 jeu. 24 juil. 2025 à 15:50, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > On Thu, Jul 24, 2025, 09:36 Elliotte Rusty Harold < > elh...@ibiblio.org> > > > > wrote: > > > > > > > > > It helps that the consumer pom still uses the old namespace, but > > > > > that's still not everything. Tools still need to analyze and > > > > > understand the build pom, not just the consumer pom. For instance, > > > > > organizations that are as paranoid about security as Google (and > with > > > > > good reason) build everything from source, and do not trust opaque > > > > > binary jars. Again, organizations that large can afford to work > > > > > around multiple namespaces, but I would like to make this more > > > > > accessible for smaller developers that also want to build tools > that > > > > > try to comprehend the build structure. > > > > > > > > > > The more I dig into this the more I worry that this is hiding some > > > > > other questionable practices where until now no one has asked the > > > > > simple question, "Why are we doing it like this?" Two in particular > > > > > are starting to concern me: > > > > > > > > > > 1. Model versions are inferred from the namespace, enabling > conflicts > > > > > that wouldn't otherwise exist. A general sense of code hygiene > > > > > suggests that there should be exactly one element defining the > model > > > > > version, and if there are two they shouldn't be allowed to disagree > > > > > with each other. Otherwise, devs are in for some nasty debugging > > > > > sessions where they think they've set something only to see > different > > > > > behavior. It's needlessly complex. > > > > > > > > > > 2. It's not just a 4.0 and 4.1 namespace. Large parts of Maven code > > > > > appear to allow any namespace at all. E.g. > > > > > http://docbook.org/ns/docbook This one might confuse tools in both > > > > > directions: the ones looking for a pom and the ones looking for > > > > > whatever the namespace purports to be. I'm not completely sure what > > > > > the implications are here — what tools it would break or holes it > > > > > might open — but it's a big world, and attackers looking to > > compromise > > > > > systems are often more devious than me. And again we don't actually > > > > > gain anything useful by allowing multiple namespaces so locking > this > > > > > down feels prudent. > > > > > > > > > > Bottom line: I'm not hearing any technical reasons why we need or > > > > > should have two namespaces for what amount to the same elements. > The > > > > > primary objection to keeping the namespace is timing. Folks are > > tired, > > > > > and want to ship. I sympathize with that. However, I fall on the > side > > > > > of the line that would prefer to see getting this right now, even > at > > > > > the cost of delaying 4.0, rather than living with a needlessly > > complex > > > > > format for the remaining decades it's likely to be in the world. > > > > > > > > > > > > > Nice message! Thank you for the explainer. I feel this can be sold as > > > > hardening, it's not just a design issue. > > > > > > > > From this user's POV, I'd rather see 4.0 get this right as I expect > to > > do > > > > migration tweaks in a major release. 5.0 feels like a million years > > away. > > > > Changing this in a further 4.x feels like an unexpected breaking > > change. > > > > > > > > HTH, > > > > Gary > > > > > > > > > > > > > On Wed, Jul 23, 2025 at 6:38 PM Guillaume Nodet <gno...@apache.org > > > > > > wrote: > > > > > > > > > > > > I think you missed an important feature of Maven 4: the consumer > > POM. > > > > > > > > > > > > In Maven 4, the consumer POM is what is deployed for the POM > > > > > accompanying a > > > > > > jar. > > > > > > That POM has a http://maven.apache.org/POM/4.0.0 + > modelVersion > > = > > > > > 4.0.0 > > > > > > so that it can be consumed by Maven 3 and other tools, gradle, > > ivy, > > > > > etc... > > > > > > This POM is rewritten from the build POM which can have a > different > > > > model > > > > > > version, > > > > > > namespace, or language (i.e. not XML). > > > > > > So if your concern is about what is deployed as POM, then you > don't > > > > have > > > > > to > > > > > > worry about it. > > > > > > > > > > > > Le mer. 23 juil. 2025 à 15:37, 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. > > > > > > > > > > > > > > > > > > > From the pom.xml, you have no simple way to get the dependency > > tree. > > > > > > Computing this tree is what the resolver does, and that's > > definitely > > > > not > > > > > a > > > > > > trivial task. We've simplified the consumer POM a bit in Maven 4 > by > > > > > > flattening the POMs, so it's a bit easier to actually compute the > > > > > effective > > > > > > POM because you don't have to flatten the hierarchy. But trying > to > > > > > > compute the dependency tree without Maven will very probably lead > > to > > > > > > a different tree than what Maven expects. > > > > > > Other build tools tend to use Maven Resolver to actually compute > > the > > > > > > dependency tree AFAIK. Which is also why we want Maven to be > more > > > > > > reusable, and that's what the Maven 4 API will provide with a > > single > > > > API > > > > > > to access all Maven features, either internally or externally. > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > Again, that's the consumer side. We did split the consumer and > the > > > > build > > > > > > POM. So, yes, the Maven community is deciding how the BUILD POM > is > > > > > > evolving, and I think that's fine. I don't see why other people > > > would > > > > > have > > > > > > to say about which feature we want to add in a particular > version. > > > > > > That does not affect other consumers from Maven Central at all. > > > > > > > > > > > > > > > > > > > -- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ------------------------ > > > > > > Guillaume Nodet > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > -- ------------------------ Guillaume Nodet
