gnodet commented on code in PR #13249:
URL: https://github.com/apache/maven/pull/13249#discussion_r4490497488
##########
impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/mvn/MavenParser.java:
##########
@@ -47,14 +56,110 @@ protected Options parseCliOptions(LocalContext context) {
throw new IllegalArgumentException("Specified file does not
exists (" + file + ")");
}
}
- // maven.config; if exists
- Path mavenConfig = context.rootDirectory != null ?
context.rootDirectory.resolve(".mvn/maven.config") : null;
- if (mavenConfig != null && Files.isRegularFile(mavenConfig)) {
- result.add(parseMavenConfigOptions(mavenConfig));
+
+ // reactor.xml <options> — used instead of maven.config when
reactor.xml is present
+ if (context.reactorConfig != null) {
Review Comment:
The current behavior is already a "supersede" rule: when `reactor.xml` is
present, its `<options>` block replaces `maven.config` entirely (the `else`
branch). The rationale is that a project opting in to `reactor.xml` has an
explicit, structured way to configure options and should not silently
accumulate both. Reading both and merging would make the interaction harder to
reason about — which file wins on conflicts?
If the concern is about projects that want to keep `maven.config` for Maven
3 compatibility while also having `reactor.xml` for Maven 4, one option is to
read `maven.config` as a base layer and let `reactor.xml <options>` override
it. That is a reasonable evolution but I would prefer to handle it in a
follow-up once the basic feature lands — the interaction semantics need more
thought.
--
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]
