gnodet commented on code in PR #13249:
URL: https://github.com/apache/maven/pull/13249#discussion_r4490494905
##########
api/maven-api-cli/src/main/java/org/apache/maven/api/cli/InvokerRequest.java:
##########
@@ -192,6 +193,20 @@ default Optional<OutputStream> stdErr() {
@Nonnull
Optional<CIInfo> ciInfo();
+ /**
+ * Returns the parsed {@code .mvn/reactor.xml} configuration, if present.
+ *
+ * <p>The configuration is parsed once during invocation setup (pre-DI)
and reused downstream.
+ * When {@code reactor.xml} is absent, this is empty and the legacy {@code
maven.config} /
+ * {@code extensions.xml} files remain in use.
+ *
+ * @return an {@link Optional} containing the {@link ReactorConfig}, or
empty if {@code reactor.xml}
+ * was not found
+ * @since 4.1.0
+ */
+ @Nonnull
+ Optional<ReactorConfig> reactorConfig();
Review Comment:
Good question. The existing `InvokerRequest` methods (`coreExtensions()`,
`ciInfo()`, etc.) each capture a distinct concern and are already part of the
public API — deprecating them all in this PR would be a larger, disruptive
refactor. The `reactorConfig()` method is intentionally additive: it surfaces
`reactor.xml` as a first-class concept without touching existing accessors.
Longer term, once `reactor.xml` stabilizes as the canonical project
configuration surface, consolidating is worth pursuing — but that is a separate
issue. Happy to open a follow-up if that direction is agreed upon.
##########
impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/mvn/ArgumentTokenizer.java:
##########
@@ -0,0 +1,97 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.cling.invoker.mvn;
+
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Quote-aware argument tokenizer for the shorthand form of {@code <options>}
and {@code <alias>} elements
+ * in {@code .mvn/reactor.xml}.
+ *
+ * <p>The algorithm is identical to {@code JvmConfigParser.parseArguments()}
(the single-file source launcher
+ * used by shell scripts to parse {@code .mvn/jvm.config}):
+ * <ul>
+ * <li>Whitespace is the delimiter outside quotes.</li>
+ * <li>{@code "..."} and {@code '...'} are both supported — quotes are
stripped, content is kept as a
+ * single token.</li>
+ * <li>Outside single-quotes, a backslash ({@code \}) escapes the next
character literally
+ * (e.g. {@code \"} → {@code "}, {@code \\} → {@code \}, {@code \ } → a
literal space).
+ * Inside single-quotes, backslash has no special meaning.</li>
+ * </ul>
+ *
+ * <p><strong>Note:</strong> {@code JvmConfigParser.java} is a self-contained
single-file source launcher
+ * invoked directly by shell scripts; it must not share classpath code with
Maven. This class is an
+ * independent re-implementation of the same algorithm for use within Maven's
Java classpath.
+ *
+ * @since 4.1.0
+ */
+public final class ArgumentTokenizer {
Review Comment:
The structured `<optionArgs>` / `<arg>` form is already supported and is the
recommended path for values containing spaces — `<options>` is just a
convenience shorthand for the common case where options are simple tokens with
no embedded whitespace (e.g. `-DskipTests -T4`). `ArgumentTokenizer` mirrors
the existing `JvmConfigParser.java` algorithm exactly and is intentionally
simple.
That said, if the preference is to keep only the typed list form and drop
`<options>` (the string form), that is feasible — it would simplify the model
and remove the tokenizer entirely. I am happy to either keep the current
dual-form approach or drop the string form; whichever the maintainers prefer.
--
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]
