Maven 4 consumer pom does not carry over mvn xml namespace

[stevenschlansker]

Affected version

4.0.0-rc-5

Bug description

I am attempting to upgrade a project to Maven 4. The project includes a build parent pom, which is a sibling module to others that use the parent.

jdbi/
  pom.xml
  jdbi-build-parent/
    pom.xml
  jdbi-core/
    pom.xml (inherit build-parent)
    src/...
  jdbi-other-integration/...

The build parent pom itself inherits from a generic template pom ( basepom )
In order to combine e.g. compiler arguments in our build parent and basepom, in our build parent we declare:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mvn="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <executions>
            <execution>
                <id>default-compile</id>
                <configuration>
                    <compilerArgs mvn:combine.children="append">
                        <arg>-Xlint:deprecation</arg>
                        <arg>-Xlint:unchecked</arg>
                    </compilerArgs>
                </configuration>
            </execution>
    </plugin>
...

We added the mvn namespace since it seemed to be the upgrade path from the old combine.children directive.

When building the multi-module project, all is well.

% mvn clean install
...
[INFO] BUILD SUCCESS

However, if you then try to use an individual project alone, without the full reactor build, you get a surprising error:

% mvn test -pl :jdbi-other-integration
...

[WARNING] The POM for org.jdbi:jdbi-core:jar:tests:4.0.0-SNAPSHOT is invalid, transitive dependencies (if any) will not be available: 1 problem was 
    - [FATAL] Non-parseable POM org.jdbi:jdbi-build-parent:4.0.0-SNAPSHOT: Unable to read model: Undeclared namespace prefix "mvn" (for attribute "combine.children")
 at [row,col {unknown-source}]: [786,64]

...

[ERROR] org.jdbi.guava.codec.TypeResolvingCodecFactoryTest.testCollectionCodec -- Time elapsed: 0.101 s <<< ERROR!
java.lang.NoClassDefFoundError: io/leangen/geantyref/GenericTypeReflector

Sure enough, the installed consumer pom lost the xmlns:mvn on the opening <project> tag:

% head ~/.m2/repository/org/jdbi/jdbi-build-parent/4.0.0-SNAPSHOT/jdbi-build-parent-4.0.0-SNAPSHOT.pom 
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">

So it looks like Maven, while transforming our build parent pom into its consumer version for installation to the local repository, drops the <project xmlns:mvn declaration and then writes an invalid POM file to the local repo.

The source is available, although it's not a minimal example: jdbi/jdbi#2935

[achyuth8055]

Hai @stevenschlansker, I would like to work on this issue and investigate why the mvn namespace
is not preserved when generating the consumer POM I will try to reproduce the issue and propose a fix.

Thanks!

[stevenschlansker]

Thank you @achyuth8055 for your excitement to look at this issue! Please let me know if there's any additional information or testing I can provide to help us move toward a solution.

Another thought I had while musing about this problem in the shower - given that the intermediate build-parent POM is actually intended to be, like its name suggests, a build-parent pom, does this mean that we should somehow treat it differently in Maven and skip writing the consumer-pom entirely? The only point of this module is to publish a build-pom internally to the project itself, and nobody should ever be using this module as a published consumer-pom.

I guess I am not sure in Maven 4 how this is supposed to work, when you want to install a build-pom to be reused for future internal-only builds, which is different than publishing a consumer-pom for external users to consume.

[elharo]

It might be OK to drop xmlns:mvn declaration but if it does that it should also be rewriting the names to not use the mvn prefix. One without the other is not OK. Likely there's a bug in the XML generation logic somewhere.

[elharo]

where is mvn:combine.children documented? Is it supposed to be in a namespace?

[stevenschlansker]

I struggled to find any documentation on combine.children in the first place, and mvn:combine.children seems to be even less documented.

I based the original change on some generated AI slop - but of course I then verified the answer seemingly accurately describes the behavior. I wish I could point to the Maven 4 docs describing this change but I never found anything authoritative looking.

AI slop below, which appears to be true to the best of my admittedly limited Maven abilities:

It sounds like you've run into one of the "clean-up" hurdles in the transition to Maven 4. While Maven 3 was fairly forgiving with custom attributes like combine.children, Maven 4 has tightened the screws on XML validation to ensure the POM stays predictable.
The short answer is: Maven 4 has moved these merging instructions into a specific namespace.
In Maven 3, combine.children and combine.self were "magical" attributes handled by the underlying Plexus configuration. In Maven 4, the parser expects the POM to follow a stricter schema. If it sees an attribute it doesn't recognize (like combine.children), it throws a validation error.
The Solution: Use the Maven 4 Namespace
To fix this, you must add xmlns:mvn="http://maven.apache.org/POM/4.0.0" and change the attribute to mvn:combine.children.

[gnodet]

Claude Code on behalf of Guillaume Nodet

After investigating this issue, we found that it actually involves two separate problems — one is a genuine Maven 4 regression, the other is a pre-existing misunderstanding of how XML namespaces work with attributes.

1. The real Maven 4 bug: invalid consumer POM (now fixed in #11823)

The consumer POM transformation drops the xmlns:mvn declaration (which lives on the <project> element and is lost during model serialization), but the prefixed attributes like mvn:combine.children survive in plugin configuration XML nodes. This produces invalid XML with undeclared namespace prefixes:

<!-- consumer POM output — invalid XML -->
<compilerArgs mvn:combine.children="append">  <!-- mvn: prefix is undeclared! -->

This is fixed in #11823 by properly handling namespace declarations and prefixed attributes on the write side. When a prefixed attribute has no corresponding xmlns: declaration, the prefix is stripped to produce valid XML.

2. mvn:combine.children never actually worked (not a regression)

This is the more subtle part. The mvn:combine.children attribute never triggered the append merge behavior, even in Maven 3. We verified this by testing with Maven 3.9.11 using a parent-child project:

Parent POM defines <compilerArgs> with -Xlint:deprecation.

Child with mvn:combine.children="append" (prefixed):

<compilerArgs mvn:combine.children="append">
    <arg>-Xlint:unchecked</arg>
</compilerArgs>

Effective POM shows only -Xlint:unchecked — the parent's -Xlint:deprecation is gone. The append directive was silently ignored.

Child with combine.children="append" (unprefixed):

<compilerArgs combine.children="append">
    <arg>-Xlint:unchecked</arg>
</compilerArgs>

Effective POM shows both -Xlint:deprecation and -Xlint:unchecked — append works correctly.

Why?

Per the XML Namespaces spec (Section 6.2), the default namespace declaration does not apply to attributes. Unprefixed attributes are in no namespace — not the default namespace, not any namespace. So:

• combine.children (unprefixed) → in no namespace
• mvn:combine.children with xmlns:mvn="http://maven.apache.org/POM/4.0.0" → in the POM namespace

These are different attributes per the XML spec. Maven's merge logic looks up combine.children (the unprefixed form), so the prefixed form is never found.

Recommendation for the jdbi project

The fix is simple: use unprefixed combine.children instead of mvn:combine.children, and remove the xmlns:mvn declaration:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="...">
    ...
    <compilerArgs combine.children="append">
        <arg>-Xlint:deprecation</arg>
        <arg>-Xlint:unchecked</arg>
    </compilerArgs>
    ...
</project>

This works in both Maven 3 and Maven 4.