Draft
Conversation
This change introduces a new execution of the Flatten Maven Plugin for non-BOM modules, aimed at simplifying their published POMs while preserving important metadata and build integrity. ### Key changes * Applies `clean` mode, removing most optional POM elements. * Retains key elements: * `<name>`, `<description>`, and `<url>` are expanded to preserve meaningful metadata and prevent undesirable URL inheritance (i.e., appending `artifactId` to the parent URL). * `<license>` is preserved in each module for clarity and utility. * Keeps the `<parent>` element so modules continue to inherit metadata and `dependencyManagement` from `log4j-bom` and their direct ancestors. * `<properties>` are removed, but `<dependencies>` and `<dependencyManagement>` are retained with interpolated values to avoid unresolved variables in the flattened POMs. ### Differences from the `clean` mode * Keeps `name` and `description` per module to aid discoverability. * Delegates all contact and project metadata (organization, developers, mailing lists, SCM, issue tracker, CI config, etc.) to the centralized `log4j-bom` POM. * Preserves `dependencyManagement` sections by interpolating versions, rather than removing them. * Retains non-transitive scopes (`provided`, `test`) to expose compile/test-time dependencies, even if consumers don't require them. This flattening strategy reduces noise in published POMs while maintaining enough structure for clarity and downstream tool compatibility.
vy
reviewed
Sep 6, 2025
| <property>parent.version</property> | ||
| <regex>12\.1\.1</regex> | ||
| <regexMessage>Remember to remove overrides from child modules, whenever the changes are moved to `logging-parent`: | ||
| * Remove the override `flatten-maven-plugin` configuration from `log4j-parent/pom.xml`.</regexMessage> |
Member
There was a problem hiding this comment.
Why do we do this? Are we intending to move this "non-BOM flattening" logic to logging-parent?
Contributor
Author
There was a problem hiding this comment.
In the long term, I think we should move this to logging-parent, don't you agree?
Member
There was a problem hiding this comment.
You're right. Could you then instead move this PR to logging-parent instead, please? We have full control over both projects and their releases. Maybe I'm missing out on certain details, but I am not able to see why we shall temporarily fix this only for Log4j, whereas fixing it in logging-parent will benefit all its children.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change introduces a new execution of the Flatten Maven Plugin for non-BOM modules, aimed at simplifying their published POMs while preserving important metadata and build integrity.
Key changes
Applies
cleanmode, removing most optional POM elements.Retains key elements:
<name>,<description>, and<url>are expanded to preserve meaningful metadata and prevent undesirable URL inheritance (i.e., appendingartifactIdto the parent URL).<license>is preserved in each module for clarity and utility.Keeps the
<parent>element so modules continue to inherit metadata anddependencyManagementfromlog4j-bomand their direct ancestors.<properties>are removed, but<dependencies>and<dependencyManagement>are retained with interpolated values to avoid unresolved variables in the flattened POMs.Differences from the
cleanmodenameanddescriptionper module to aid discoverability.log4j-bomPOM.dependencyManagementsections by interpolating versions, rather than removing them.provided,test) to expose compile/test-time dependencies, even if consumers don't require them.This flattening strategy reduces noise in published POMs while maintaining enough structure for clarity and downstream tool compatibility.
Another advantage of this approach is that the Flatten Maven Plugin computes the effective POM using the already flattened parent POMs, unlike Maven’s reactor, which uses the source POM files. This helps catch issues early and prevents unresolved properties from being accidentally propagated into the published POMs.
While this change will likely belong in
logging-parenteventually, this PR is currently targeted here (and marked as a draft) for two main reasons:logging-parent.2.25.2without incurring the additional overhead of releasing a new version oflogging-parent.