Yup, only some projects like JRuby ihttps://github.com/jruby/jruby/blob/master/.mvn/extensions.xml Tycho https://github.com/eclipse-tycho/tycho/blob/ba763d5e2f1920037a043f6086f8fde54a442ea7/tycho-extras/tycho-pomless/pom.xml#L36 etc
On Thu, Mar 19, 2026 at 5:37 PM Benjamin Marwell <[email protected]> wrote: > > <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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
