<https://github.com/takari/polyglot-maven>
But I've never seen that be used in any real project, but that's just me. - Ben On 16 March 2026 12:43:10 CET, Gary Gregory <[email protected]> wrote: >On Mon, Mar 16, 2026 at 6:31 AM Romain Manni-Bucau ><[email protected]> wrote: >> >> it is where maven always had been weird-ish, it relies heavily on XML but >> doesn't actualy embrace XML - just cause of one line. > >Where Maven XML is broken, IMO, is that it uses elements for >everything, which makes the verbosity so much worse. > ><dependency groupId="a" artifactId="b" version="1" /> > >oh the relief that would be... > >Gary > >> the impact is that if you need some extension configuration to inject in >> the pom - natural compared to have pom.xml extension1.xml, extension2.json >> etc..., then you must use properties or plugin configuration even when not >> needed. >> Guillaume made some enhancement on that but namespaces are designed for >> that and don't have any issue nor maven has any nor any consuming tool as >> soon as they do parse XML. >> The only issue we can get if we do want portable pom, ie extensionless >> otherwise the pom is no more the only source of truth and all that is >> pointless. >> >> So yes modelVersion can be used as a source but a namespace as well and it >> doesn't imply any remoting even using https://... since we do embed xsd in >> the project. >> >> So overall, from my window it is 100% a style decision. >> >> The only point which can weight there for me is if we do support >> polygloting or we consider it is an extension we don't care about - I'm >> fine both ways since it is broken in IDE anyway. >> If we think it is a core/important feature, namespacing can make it complex >> for nothing and modelVersion is easier but it is the only real criteria for >> maven 4 IMHO, other points are wrong technically. >> >> 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 founder (Java/.NET service - contact via linkedin) >> >> >> Le lun. 16 mars 2026 à 11:08, Björn Raupach <[email protected]> a écrit : >> >> > Elliot, I don’t want to stir up a hornet’s nest, but could you give me a >> > specific example of where it would cause a problem? >> > >> > In Maven 3.9.x the namespace declaration never mattered in all the >> > projects I used it with. I fail to understand why it matters in Maven 4. >> > >> > All these allow Maven to execute and run: >> > >> > <project> >> > <modelVersion>4.0.0</modelVersion> >> > <groupId>com.mycompany.app</groupId> >> > <artifactId>my-app</artifactId> >> > <version>1</version> >> > </project> >> > >> > <project xmlns="foo"> >> > <modelVersion>4.0.0</modelVersion> >> > <groupId>com.mycompany.app</groupId> >> > <artifactId>my-app</artifactId> >> > <version>1</version> >> > </project> >> > >> > <project xmlns="xmlns=http://maven.apache.org/POM/4.0.0”> >> > <modelVersion>4.0.0</modelVersion> >> > <groupId>com.mycompany.app</groupId> >> > <artifactId>my-app</artifactId> >> > <version>1</version> >> > </project> >> > >> > I admit that my expertise in XML is limited, but I worked with XML in a >> > highly regulated environment. They used XML namespaces and schemas >> > extensively. >> > >> > In that project, XML documents were a composition of many XML documents, >> > each with its own XML namespaces and schema. >> > Every element and attribute hat do use a qualified name. >> > The XML namespaces were used to avoid element names clashes, because >> > some elements had the same name, but belonged to a different "XML >> > vocabulary". >> > Therefore, it made sense to qualify every element with its prefix. >> > >> > Isn’t this the only reason why we need namespaces in the first place? I >> > have never seen a qualified name in any pom.xml in the last twenty >> > years. >> > >> > The XML schema was used to verify the various XML documents that made up >> > the larger XML document. >> > The schema ensured that the vocabulary, i.e. the sum of XML elements and >> > attributes for that part of the document was used correctly. >> > Nothing more. While this was useful, the namespace itself was never >> > verified using the XML schema. I don't think that's even possible. >> > >> > Namespaces do nothing more than avoid name collisions. Maven does not >> > have a problem with names coming from different sources. >> > >> > Am 16.03.2026 08:20 schrieb Guillaume Nodet: >> > > Regarding the namespace discussion, I'd like to better understand the >> > > concrete difficulty with processing POMs that have different >> > > namespaces. >> > > >> > > In XSLT, a simple namespace normalization pre-processing step handles >> > > this: >> > > >> > > <xsl:template match="*"> >> > > <xsl:element name="{local-name()}" >> > > namespace="http://maven.apache.org/POM/4.0.0"> >> > > <xsl:apply-templates select="@*|node()"/> >> > > </xsl:element> >> > > </xsl:template> >> > > >> > > In XPath, you can use local-name(): >> > > //*[local-name()='dependency'] >> > > >> > > Or in XPath/XSLT 2.0+, wildcard namespace matching: >> > > //*:dependency >> > > >> > > I want to make sure we're weighing the actual cost accurately on both >> > > sides >> > > before making a decision. >> > > >> > > Guillaume >> > > >> > > >> > > Le sam. 14 mars 2026 à 22:15, Elliotte Rusty Harold >> > > <[email protected]> a >> > > écrit : >> > > >> > >> On Sat, Mar 14, 2026 at 4:17 PM Hervé Boutemy <[email protected]> >> > >> wrote: >> > >> > >> > >> > sorry, I don't get what has been done, "years ago": can you explain? >> > >> > >> > >> > and TBH, I don't get what changing namespace value really breaks >> > beyond >> > >> some >> > >> > very theoretical aspect: so changing or not changing in one or the >> > other >> > >> > direction, what does it break? >> > >> >> > >> I have said this before. I'm guess I'm going to have to say it again. >> > >> The problems are not theoretical. I have personally spent extra months >> > >> of development on projects (which Google paid for at the time, so >> > >> probably six figures worth of Google's money) because I could not use >> > >> standard XML tooling like XSLT and XPath to process pom.xml files. The >> > >> specific reason was Maven not using namespaces as designed and >> > >> documented in the Namespaces in XML specification. Adding new >> > >> namespaces makes the problem worse. >> > >> >> > >> There are other tools I have never bothered to build because they'd >> > >> simply be too challenging and expensive to create. >> > >> >> > >> There is no benefit to introducing new namespaces with every version >> > >> of Maven and substantial cost. The burden of proof is on those who >> > >> claim we should change the namespace and work against the design of >> > >> XML namespaces. >> > >> >> > >> -- >> > >> Elliotte Rusty Harold >> > >> [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] >> > >> > > >--------------------------------------------------------------------- >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]
