gnodet-bot commented on code in PR #1542:
URL: https://github.com/apache/maven/pull/1542#discussion_r4052421012
##########
maven-core/src/test/resources/projects/duplicate-plugins-merged-pom.xml:
##########
@@ -24,25 +25,36 @@
</execution>
</executions>
</plugin>
- <plugin>
- <artifactId>maven-compiler-plugin</artifactId>
- <dependencies>
- <dependency>
- <groupId>group</groupId>
- <artifactId>second</artifactId>
- <version>1</version>
- </dependency>
- </dependencies>
- <executions>
- <execution>
- <id>second</id>
- <goals>
- <goal>compile</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- </plugins>
+ </plugins>
</build>
+ <profiles>
+ <profile>
+ <id>foo</id>
+ <activation><activeByDefault>true</activeByDefault></activation>
Review Comment:
⚠️ **`activeByDefault` is fragile in merge tests.**
The original POM had two `maven-compiler-plugin` declarations directly in
`build/plugins` (a true raw-model duplicate). Moving the second declaration
into a profile with `activeByDefault=true` changes the activation semantics:
this profile is silently deactivated whenever **any other profile** is
explicitly activated during the build (Maven's well-known `activeByDefault`
gotcha).
In CI, if the test runner activates a profile (e.g. `-Prun-its`, any
toolchain profile, or a profile triggered by property/OS), the `foo` profile
will be deactivated and `testDuplicatePluginDefinitionsMerged` will fail —
`getBuildPlugins().get(0).getDependencies().size()` will return 1 instead of 2,
and `.getExecutions().size()` will return 1.
Consider using an explicit property-based activation instead:
```suggestion
<activation><property><name>!skipFooProfile</name></property></activation>
```
Or, better: keep the duplicate in `build/plugins` but add `<version>` to
each declaration (to satisfy the new strict-level duplicate-plugin check and
prevent the raw validation ERROR), then verify the merged result. That would
test both the 3.1-level error path and the merge behaviour in a single,
environment-independent fixture.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
