gnodet-bot commented on code in PR #13491:
URL: https://github.com/apache/maven/pull/13491#discussion_r4492513225
##########
apache-maven/src/assembly/maven/bin/mvn.cmd:
##########
@@ -390,25 +390,41 @@ goto processArgs
:endHandleArgs
call :processArgs %*
-for %%i in ("%MAVEN_HOME%"\boot\plexus-classworlds-*) do set LAUNCHER_JAR="%%i"
+set LAUNCHER_JAR="%MAVEN_HOME%\boot\*"
set LAUNCHER_CLASS=org.codehaus.plexus.classworlds.launcher.Launcher
+set MODULES_DIR="%MAVEN_HOME%\lib\modules"
if "%MAVEN_MAIN_CLASS%"=="" @set
MAVEN_MAIN_CLASS=org.apache.maven.cling.MavenCling
-@REM Only pass MAVEN_ARGS for the default Maven build command (MavenCling),
+@rem Module-path and native access flags require a JDK that can read the
module jars.
+@rem The probe includes --module-path so it fails on JDKs that cannot read the
module descriptors.
+@rem Fall back to ALL-UNNAMED so that --enable-native-access is always granted
on JDK 22+,
+@rem even when the module-path probe fails (older JDK, missing lib\modules\,
locked-down env).
+set MAVEN_MODULE_OPTS=--enable-native-access=ALL-UNNAMED
+"%JAVACMD%" --module-path %MODULES_DIR% --add-modules ALL-MODULE-PATH
--enable-native-access=org.jline.terminal.ffm -version >NUL 2>&1
+if not ERRORLEVEL 1 (
+ set MAVEN_MODULE_OPTS=--module-path %MODULES_DIR% --add-modules
ALL-MODULE-PATH --enable-native-access=org.jline.terminal.ffm,org.jline.nativ
+)
+
+@REM MAVEN_ARGS is only passed for the default Maven build command
(MavenCling),
@REM not for sub-commands like --up, --enc, --shell or --val which have their
own options.
-if not "%MAVEN_MAIN_CLASS%"=="org.apache.maven.cling.MavenCling" set
"MAVEN_ARGS="
+@REM IS_MAIN_OVERRIDE is set during argument scanning when any of those flags
is found.
+if defined IS_MAIN_OVERRIDE (
+ set "MAVEN_EFFECTIVE_ARGS="
+) else (
+ set "MAVEN_EFFECTIVE_ARGS=%MAVEN_ARGS%"
+)
if defined MAVEN_DEBUG_SCRIPT (
echo [DEBUG] Launching JVM with command:
- echo [DEBUG] "%JAVACMD%" %INTERNAL_MAVEN_OPTS% %MAVEN_OPTS%
%JVM_CONFIG_ARGFILE_ARG% %MAVEN_DEBUG_OPTS% --enable-native-access=ALL-UNNAMED
-classpath %LAUNCHER_JAR% "-Dclassworlds.conf=%CLASSWORLDS_CONF%"
"-Dmaven.home=%MAVEN_HOME%" "-Dmaven.mainClass=%MAVEN_MAIN_CLASS%"
"-Dlibrary.jline.path=%MAVEN_HOME%\lib\jline-native"
"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
%MAVEN_VERSION_PRINTED% %LAUNCHER_CLASS% %MAVEN_ARGS% %*
+ echo [DEBUG] "%JAVACMD%" %INTERNAL_MAVEN_OPTS% %MAVEN_OPTS%
%JVM_CONFIG_ARGFILE_ARG% %MAVEN_DEBUG_OPTS% %MAVEN_MODULE_OPTS% -classpath
%LAUNCHER_JAR% "-Dclassworlds.conf=%CLASSWORLDS_CONF%"
"-Dmaven.home=%MAVEN_HOME%" "-Dmaven.mainClass=%MAVEN_MAIN_CLASS%"
"-Dlibrary.jline.path=%MAVEN_HOME%\lib\jline-native"
"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%" %LAUNCHER_CLASS%
%MAVEN_EFFECTIVE_ARGS% %*
Review Comment:
💡 **Debug echo missing `%MAVEN_VERSION_PRINTED%`**
The old debug echo line included `%MAVEN_VERSION_PRINTED%` before
`%LAUNCHER_CLASS%`. The new line drops it. The actual JVM launch at line 434
correctly passes `%MAVEN_VERSION_PRINTED%`, but `MAVEN_DEBUG_SCRIPT` output
will silently omit `-Dmaven.version.printed=true`, making the debug trace
misleading for anyone investigating version-printing behavior.
```suggestion
echo [DEBUG] "%JAVACMD%" %INTERNAL_MAVEN_OPTS% %MAVEN_OPTS%
%JVM_CONFIG_ARGFILE_ARG% %MAVEN_DEBUG_OPTS% %MAVEN_MODULE_OPTS% -classpath
%LAUNCHER_JAR% "-Dclassworlds.conf=%CLASSWORLDS_CONF%"
"-Dmaven.home=%MAVEN_HOME%" "-Dmaven.mainClass=%MAVEN_MAIN_CLASS%"
"-Dlibrary.jline.path=%MAVEN_HOME%\lib\jline-native"
"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
%MAVEN_VERSION_PRINTED% %LAUNCHER_CLASS% %MAVEN_EFFECTIVE_ARGS% %*
```
##########
apache-maven/src/assembly/component.xml:
##########
@@ -25,16 +25,22 @@ under the License.
<includes>
<include>org.apache.maven:maven-classworlds</include>
</includes>
- <!-- Preserve the legacy plexus-classworlds-*.jar file name for backward
compatibility:
- wrapper scripts, CI tooling, and IDEs that glob
boot/plexus-classworlds-*.jar continue
- to work without change after the internalization. -->
-
<outputFileNameMapping>plexus-classworlds-${artifact.version}.jar</outputFileNameMapping>
</dependencySet>
Review Comment:
❓ **`outputFileNameMapping` removal — intentional breaking change?**
The removed comment explicitly stated this mapping existed "for backward
compatibility: wrapper scripts, CI tooling, and IDEs that glob
`boot/plexus-classworlds-*.jar`". Dropping it means the maven-classworlds jar
is now named `maven-classworlds-${version}.jar` in `boot/`, not
`plexus-classworlds-*.jar`.
The `mvn` and `mvn.cmd` scripts are updated to use `boot/*.jar`, so Maven
itself still works. But external tooling that globs specifically for
`plexus-classworlds-*.jar` (IDE classpath resolution, CI scripts, Maven wrapper
implementations) will break silently. Is this an intentional maven4-only
breaking change, or should the `outputFileNameMapping` be retained until a
formal compatibility notice is in place? Worth a note in the PR description or
a CHANGELOG entry if intentional.
--
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]
