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