On Fri, Mar 27, 2026 at 11:03 AM Maarten Mulders <[email protected]> wrote:
>
> Let me try to wrap up my current understanding of where we are:
>
> 1. The namespace is used to infer the model version.

Sometimes, but it doesn't need to be. We have a mdoelVersion element
for that, and having two ways to do the same thing is another footgun.

> 2. The model version determines which inference Maven will apply when
> reading the POM file from disk.

I'm not sure what you mean by that.

> 3. The POM file on disk can never describe the full model Project Object
> Model, as many of that model is inferred and/or inherited.

> Given 3. (and 2.) I think we should state: "understanding a POM file on
> disk is not possible without using the Maven libraries that read, parse
> and interpret it". This statement applies to any POM file, regardless of
> whether it is XML or another format.
>
> Q: Does that make sense?

No, it does not. Some things need the full Maven toolchain. A lot of
things don't. Don't forget that poms are used by gradle, ivy, and
other non-Maven tools. This isn't just about building with Maven. Code
that works with pom files is easier and cheaper to write when it can
rely on XSLT, XPath, and other XML tools.

> I think a potential conclusion could be that support for tools outside
> the Maven libraries to "understand" or "process" a POM file on disk is
> not our priority or maybe not even our concern.

It should be. That's at least a big a community as people who use
Maven, probably larger. Maven is one client of the Maven repository
system, but hardly the only one.

> One more thing: In the XML world, we derive the model version from the
> namespace. I will leave it in the middle if that is good or bad, that's
> just how it works today. How is that supposed to work in other, non-XML
> formats, that might not have the notion of namespaces?

No, we derive the model version from the modelVersion element.

-- 
Elliotte Rusty Harold
[email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to