[MPH-175] mvn help:effective-pom leaves <parent> pom in place

[jira-importer]

Georg Lippold opened MPH-175 and commented

When executing mvn help:effective-pom, the <parent> XML node is left intact. The <parent> should be removed in the effective POM.

If you generate the effective pom to modify the project, e.g. to remove or override settings that are present in the parent pom, then including the <parent> node in the resulting XML re-introduces the settings that you wanted to modify.

Example: <parent> specifies a setting, e.g.

<project>
  <properties>
    <format>HTML</format>
  </properties>
</project>

If the <format> node is now removed from the effective POM, then it is re-introduced by including the <parent> in every maven run. The parent POM should not be required anymore in an effective POM, because all its settings should already be included in the effective POM.

---

Affects: 3.2.0

[jira-importer]

Jeremie Bresson commented

I think the feature you are interested in is provided by the flatten-maven-plugin
https://www.mojohaus.org/flatten-maven-plugin/index.html

<dependency>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>flatten-maven-plugin</artifactId>
    <version>${version}</version>
</dependency>

[elharo]

Per Gemini:

This is not a bug, and it is an unreasonable request based on a misunderstanding of the maven-help-plugin's purpose.

The user is attempting to use a diagnostic tool as an export tool, which is an anti-pattern in Maven. The request is flawed for the following technical reasons:

1. Diagnostic vs. Transformation Purpose: The help:effective-pom goal is strictly a diagnostic tool designed to display the POM that Maven uses during a build, after inheritance, interpolation, and active profiles are resolved. It is meant to be read by developers to troubleshoot builds, not to be saved and used as a replacement pom.xml.
2. Model Integrity: In the Maven Project Object Model (POM), inheritance is a core structural element. Even after properties and plugin configurations are interpolated from the parent, the project's identity (and often its implicit groupId and version) remains tied to that parent. Removing the <parent> node would inaccurately represent the Maven project state.
3. Existing Tooling: The specific use case the user describes—generating a resolved, standalone POM that strips out the parent hierarchy so it can be deployed or modified independently—is exactly what the flatten-maven-plugin is designed to do.

While the issue was imported from Jira with a bug label, the described behavior is the correct and intended functionality of mvn help:effective-pom. Modifying it to drop the <parent> tag would break its diagnostic accuracy.

I'm not actually 100% convinced of this, so if someone wants to argue otherwise, please comment and we can consider reopening.