Consumer POM of parent POMs currently remain at modelVersion 4.1.0, breaking Maven 3 and Gradle consumers

[gnodet]

Affected version

4.0.0-rc5, probably caused by #11370 in 4.0.0-rc5

Summary

When a project is built with Maven 4 using model version 4.1.0, the consumer POM transformation successfully downgrades child artifact POMs (jars, etc.) to model version 4.0.0. However, parent POMs (POM-packaged projects) by design remain at model version 4.1.0 in their consumer POM, because the transformation only strips some 4.1.0 features (root, subprojects, preserveModelVersion) but not others (condition/packaging in profile activation, extension configuration, build sources).

But since child artifact consumer POMs retain a <parent> reference (with only relativePath removed), Maven 3 and Gradle resolve the parent POM, encounter model version 4.1.0, and fail.

Reproduction / Example

This is happening in the wild with JLine 4.0.0, which was built with Maven 4 using model version 4.1.0:

• The child artifact POMs (e.g., jline-reader-4.0.0.pom) are correctly transformed to model version 4.0.0
• But they reference org.jline:jline-parent:4.0.0 as their parent
• The parent POM jline-parent-4.0.0.pom has <modelVersion>4.1.0</modelVersion>
• Maven 3 and Gradle cannot parse model version 4.1.0 and fail

See: jline/jline3#1688

Impact

This is a critical compatibility issue. Any project built with Maven 4 that uses model version 4.1.0 features in its parent POM chain will produce artifacts that cannot be consumed by:

• Maven 3
• Gradle (all versions)
• Any other tool that only supports model version 4.0.0

This effectively breaks the backwards compatibility promise of Maven 4's consumer POM mechanism.

Analysis

The consumer POM transformation in DefaultConsumerPomBuilder.transformPom() does the following for POM-packaged projects:

• Strips root, modules, subprojects ✓
• Strips preserveModelVersion ✓
• Strips relativePath from parent ✓
• Computes the minimum model version via MavenModelVersion.getModelVersion() ✓

But several 4.1.0 features are not stripped, causing the model version to remain 4.1.0:

• Profile activation condition
• Profile activation packaging
• Extension configuration
• Build sources (only conditionally stripped)

Even if all these were stripped, the problem is recursive: the parent POM's own parent may also be 4.1.0, and so on up the chain. The fundamental issue is that the consumer POM of a POM-packaged project retains the <parent> reference, and there is no guarantee that the entire parent chain is 4.0.0-compatible.

[gnodet]

Proposed Solution: Dual Consumer POMs with Classifier-Based Parent Resolution

Core Idea

Deploy two consumer POMs for POM-packaged projects (parents):

Artifact	Model Version	Content	Consumer
Main POM (no classifier)	4.0.0	4.1.0 features stripped, parent reference kept (pointing to parent's main POM, also 4.0.0)	Maven 3, Gradle, other tools
consumer classifier	4.1.0	Full-fidelity consumer POM with all features preserved, parent reference pointing to parent's consumer classifier	Maven 4
build classifier	4.1.0	Original build POM (unchanged from today)	Maven 4 builds

How It Works

For POM-packaged projects (parents), during consumer POM generation:

1. Main POM (4.0.0): transformPom() aggressively strips all remaining 4.1.0 features from the consumer POM:

   • Profile activation condition → stripped or converted to legacy activation
   • Profile activation packaging → stripped
   • Extension configuration → stripped
   • Build sources → stripped
   • Force model version to 4.0.0
   • Keep the <parent> reference as-is — this is safe because the parent's main POM follows the same convention and is also 4.0.0

2. Consumer classifier POM (4.1.0): the current consumer POM output, unchanged, preserving all features. The <parent> element references the parent's consumer classifier.

For non-POM projects (jars, etc.): behavior is unchanged — parent is already stripped (parent(null)), model version already downgraded to 4.0.0.

Maven 4 Parent Resolution

Maven 4 needs to support classifier-based parent resolution:

• Add <classifier> support to the <parent> element in the 4.1.0+ model
• The consumer classifier POM uses <parent><classifier>consumer</classifier></parent> to reference the parent's full-fidelity consumer POM
• The main (4.0.0) POM has no classifier on its parent — Maven 3 resolves it normally

This keeps the POM self-describing: any tool reading the POM knows exactly which artifact to resolve, without relying on implicit resolution conventions.

Why This Avoids the Flattening Problem (#11346)

The main (4.0.0) POM is not flattened — it does not inline parent inheritance or modify dependency management. It only strips 4.1.0 model features that Maven 3 cannot understand. The <parent> reference and dependency management inheritance chain remain intact, so the dependency management "depth" is unchanged and #11346 does not apply.

Maven 3 consumers lose access to 4.1.0-specific features (profile conditions, extension configuration, etc.), but these features were never supported by Maven 3 in the first place.

What Needs to Change

1. POM Model (4.1.0): Add optional <classifier> to <parent> element
2. DefaultConsumerPomBuilder: Generate two consumer POMs for POM-packaged projects — one with features stripped (4.0.0), one with full fidelity (4.1.0, referencing parent's consumer classifier)
3. ConsumerPomArtifactTransformer: Deploy both consumer POMs with appropriate classifiers
4. Maven 4 parent resolution (DefaultModelBuilder / resolver): Support resolving parent POMs with a classifier
5. MavenModelVersion: Ensure the 4.0.0 variant passes the version check after all 4.1.0 features are stripped

Limitations

• Existing artifacts: Projects already deployed with 4.1.0 parent POMs (like JLine 4.0.0) would need a re-release to benefit from this fix
• Feature loss for Maven 3: Maven 3 consumers of a Maven 4-built parent lose 4.1.0-only features (profile conditions, etc.) — this is an acceptable trade-off since Maven 3 never supported them

[hboutemy]

@gnodet I'm looking at this

But since child artifact consumer POMs retain a reference

from the thinking we had in the past about build/consumer POMs, at that time we thought about the question of parent POMs published to Maven Central or even local repository.
At that time, because of the complexity of profiles etc..., we thought that for parent POMs, it was very "build-only" then:

1. parent would be published only in their original form, 4.1.0 when project upgrades
2. child artifacts would drop their parent link in the consumer POM and just become standalone without parent, to avoid the new format

at that time, this was thought as the most simple

is there a reason to not "just" do that, beyond the impact on size of the child consumer POM = the key impact we found?
Is there a strong win at keeping a parent to a consumer POM?

EDIT now I read the flattening #11346 reference about this, I did not read everything :)

[gnodet]

@hboutemy Good question — you're right to revisit the flattening approach.

The dual consumer POM approach is a direct consequence of not flattening child consumer POMs (i.e., keeping the <parent> reference). The chain of reasoning is:

1. Add ability to disable consumer POM flattening to preserve dependency management inheritance #11346 showed that flattening consumer POMs can lose "unused" managed dependencies that downstream consumers actually need (when they override a transitive dependency version, bringing in new transitive deps that the removed management would have controlled)
2. The response was to stop flattening — keep the <parent> reference in consumer POMs
3. But keeping <parent> means the parent POM must be resolvable from the repository
4. If the parent uses 4.1.0 features and only a stripped 4.0.0 consumer POM is published, Maven 4 consumers lose those features
5. Hence dual consumer POMs — publish both a 4.0.0 stripped version and a 4.1.0 full-fidelity version

Alternatives

We could avoid dual consumer POMs entirely if we go back to flattening. This is possible if either:

1. Fix managed dep removal separately: stop filtering "unused" managed dependencies during flattening. This fixes the root cause of Add ability to disable consumer POM flattening to preserve dependency management inheritance #11346 while keeping consumer POMs self-contained and 4.0.0-compatible. The <parent> reference is dropped, everything is inlined, no parent resolution needed.
2. Accept the managed dep loss: keep flattening as-is, acknowledging that some edge cases (Add ability to disable consumer POM flattening to preserve dependency management inheritance #11346 scenario) may break. This is the simplest approach but has known issues.

Flattening vs. non-flattening trade-offs

	Flatten (drop parent)	Non-flatten (keep parent)
Consumer POM size	Larger (all content inlined)	Smaller (inherits from parent)
Parent resolution	Not needed	Required → dual consumer POMs for 4.1.0+ parents
#11346 managed deps	Need fix (stop removing "unused" managed deps)	Not an issue (inheritance preserved)
Complexity	Simpler deployment (one consumer POM)	More complex (two consumer POMs + classifier resolution)
Future model versions (mixins etc.)	Works — mixin content resolved at build time and inlined	Works — mixin references preserved in full-fidelity POM

My take

The simplest path forward might be:

• Fix Add ability to disable consumer POM flattening to preserve dependency management inheritance #11346 at its root (stop removing unused managed deps during flattening) as a separate PR
• Flatten consumer POMs (drop <parent>, inline everything) — as was originally designed
• No dual consumer POMs needed

The dual consumer POM approach in PR #11775 solves the problem but introduces significant complexity (classifier-based parent resolution, dual artifact deployment, model schema changes). If we can fix managed dep removal, the original flattening approach handles everything including future model versions like 4.2.0 mixins — since mixin content is resolved at build time and inlined into the flattened consumer POM.

What are your thoughts on the flattening + fix managed dep removal approach?

[gnodet]

Following up on the flattening discussion — after more analysis, here's where I'm landing:

The managed dep removal question

In my previous comment, I suggested fixing #11346 by not removing "unused" managed deps during flattening. But that's not practical: when using BOMs like Spring Boot or Quarkus, flattening without removal would bloat every consumer POM with hundreds of irrelevant managed dep entries. That's why the removal was added in the first place.

And non-flattening doesn't really help here either — keeping the <parent>/BOM reference avoids the bloat in the POM file, but those hundreds of managed deps are still resolved during dependency resolution. Same cost, different place.

Rethinking #11346

The #11346 scenario relies on managed deps "leaking through" from a transitive dependency's POM to control versions in the consumer's graph. Specifically: consumer A depends on B:1.0 (no transitive deps), A's parent manages C:1.2 (appears "unused"). Consumer D overrides B to 2.0, which brings in C:1.1 transitively, and expects A's managed C:1.2 to kick in.

This is really a dependency alignment problem. Relying on implicit managed dep inheritance through the transitive graph is fragile. The right answer is for consumer D to handle alignment explicitly — via <scope>import</scope> BOMs, enforced platforms (Quarkus/Spring Boot style), or a future Maven alignment mechanism.

If we treat #11346 as "not a bug, just an unsupported use case", then:

• Removing unused managed deps during flattening is fine (keeps POMs lean)
• Flattening remains a good default

So do we still need dual consumer POMs?

This brings us back to the core question: is there a strong reason to support non-flattened consumer POMs at all?

If flattening + removal is the right default, then dual consumer POMs are only needed when someone explicitly opts out of flattening. The question is whether that opt-out path needs to exist, and if so, whether it justifies the complexity of dual consumer POMs + classifier-based parent resolution.

Thoughts?

[gnodet]

Following up on the discussion — after more analysis, we are closing the dual consumer POM PR (#11775). Here is why and what we propose instead.

Why dual consumer POMs are unnecessary

Maven already deploys the original POM with a build classifier. If Maven 4 needs full-fidelity parent resolution, it can resolve the build POM. There is no need for a third artifact (consumer classifier POM) with its own resolution mechanism (<classifier> on <parent>).

Furthermore, the PR description claimed that "stripping is a dead end because of mixins (4.2.0)." But this is flawed reasoning — mixins cannot be stripped without losing content regardless, so the 4.0.0 backward-compatible POM must be flattened (mixin content resolved and inlined). The dual consumer POM approach does not avoid flattening for mixins either.

Revised proposal

The actual fixes needed are simpler:

1. Flag for managed dependency removal during flattening

Currently, "unused" managed dependencies are removed during consumer POM flattening to keep POMs lean (important when using BOMs like Spring Boot or Quarkus with hundreds of managed entries). This should be controllable via a property (e.g., maven.consumer.pom.removeManagedDependencies), defaulting to true (current behavior). Users who hit the #11346 edge case can set it to false.

Note: we consider #11346 an edge case, not a bug. Relying on managed deps leaking through transitive dependency POMs is fragile and implicit. Proper dependency alignment (import-scoped BOMs, enforced platforms) is the right solution for that use case.

2. Build validation when flattening is disabled

If a user disables flattening (maven.consumer.pom.flatten=false) and their parent POM uses 4.1.0+ features that cannot be represented in a non-flattened consumer POM (since the parent reference would point to the stripped 4.0.0 parent, losing features), Maven should reject the build with a clear error message explaining that flattening must be enabled.

This prevents silent loss of consuming-time information without requiring the complexity of dual consumer POMs.

3. Consider re-enabling flattening as default

Flattening was disabled in response to #11346, but if we treat that as an unsupported use case (dependency alignment should be explicit), flattening could be re-enabled as the default, keeping consumer POMs lean and self-contained.

Summary

Approach	Complexity	Backward compat	Maven 4 full-fidelity	POM size
Dual consumer POMs	High (new classifier, resolution logic, schema changes)	Yes	Yes (via consumer classifier)	Small
Flatten + flag + validation	Low (flag + validation check)	Yes (flattened 4.0.0)	Yes (via build classifier)	Lean (with removal) or larger (without)

The second approach achieves the same goals with far less complexity.