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

Reply via email to