ppkarwasz commented on code in PR #265: URL: https://github.com/apache/logging-parent/pull/265#discussion_r1795804436
########## pom.xml: ########## @@ -1018,6 +944,83 @@ <profiles> + <!-- `bom` profile to generate BOMs --> + <profile> + + <id>bom</id> + + <!-- Profile gets activated using a file instead of, say, a property defined by the child `pom.xml`. + Since a Maven property lookup requires model interpolation and that happens after the profile activation phase. + See: https://maven.apache.org/ref/3.9.6/maven-model-builder --> + <activation> + <file> + <exists>.logging-parent-bom-activator</exists> + </file> + </activation> + + <build> + <plugins> + + <plugin> + <groupId>org.codehaus.mojo</groupId> + <artifactId>flatten-maven-plugin</artifactId> + <executions> + + <!-- Explicitly specifying the `flatten-revision` execution to set its order in execution --> + <execution> + <id>flatten-revision</id> + </execution> + + <!-- BOMs should ideally _only_ contain dependencies for modules of the project. + No invasive properties or plugin/dependency management – either from the BOM itself or its parent. + The following execution exactly performs that trimming operation. --> + <execution> + <id>flatten-bom</id> + <goals> + <goal>flatten</goal> + </goals> + <phase>process-resources</phase> + <configuration> + <flattenMode>bom</flattenMode> + <!-- POM `ElementHandling` is pretty cryptic: https://www.mojohaus.org/flatten-maven-plugin/apidocs/org/codehaus/mojo/flatten/ElementHandling.html + Trial-and-error has shown that we should use either `remove` or `interpolate`. + `remove` simply removes the element. + `interpolate` takes the element from the original POM with variables interpolated. + Avoid using `resolve`, which uses the effective POM where inherited changes from the parent are also incorporated. --> + <pomElements> + <build>remove</build> + <dependencyManagement>interpolate</dependencyManagement> + <distributionManagement>remove</distributionManagement> + <profiles>remove</profiles> + <properties>remove</properties> + <repositories>remove</repositories> + <!-- Keep the `parent`! + Otherwise, this causes build failures for artifacts whose dependencies need to be resolved at runtime. + Consider the following problem experienced in `log4j-changelog-maven-plugin`: + + 1. `log4j-changelog-maven-plugin` depends on `log4j-changelog` + 2. `log4j-changelog` inherits from `log4j-tools-parent` + 3. `log4j-tools-parent` inherits from `log4j-tools-bom` + 4. `log4j-tools-bom` inherits from `logging-parent` + 5. `logging-parent` contains `dependencyManagement`, etc. entries that are used by `log4j-changelog-maven-plugin` + 6. Dependencies of `log4j-changelog-maven-plugin` et al. is resolved *at runtime* + 7. Though at runtime, the deployed `log4j-tools-bom` is used, which is flattened and hence doesn't have a parent! + 8. Hence, at runtime, `log4j-transform-maven-plugin` execution fails due to missing logic that should have been inherited from `logging-parent` + + To avoid this, parents should better be kept while flattening BOMs. --> + <parent>keep</parent> Review Comment: Do we need this? Our troubles were caused exactly by https://github.com/apache/logging-log4j2/issues/3066, which is fixed by this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
