ascheman commented on PR #362:
URL: https://github.com/apache/maven-wrapper/pull/362#issuecomment-5011334371
I looked into this while triaging M4-related PRs and verified the behavior
against the actual `m2.conf` files:
* Maven 3.9.x: `main is org.apache.maven.cli.MavenCli` — hardcoded,
`${maven.mainClass}` is never interpolated, so this change is indeed a no-op
for Maven 3.
* 4.0.0-beta-5…rc-4: `main is ${maven.mainClass}` **without** a default —
broken when launched via wrapper (which boots classworlds directly, bypassing
`bin/mvn`); this PR fixes exactly those versions.
* 4.0.0-rc-5+: `set maven.mainClass default
org.apache.maven.cling.MavenCling` (f77fe3cbb84) — works without this PR.
One concern with merging it as-is: for rc-5+ the script *overrides* the
distribution's default with a hardcoded internal class name, baked into every
generated `mvnw` for years. If a future Maven version ever renames its main
class (updating its own m2.conf default accordingly), wrapper-launched builds
would still force the stale name and fail with `ClassNotFoundException` —
today's no-op becomes tomorrow's breakage.
If the goal is keeping beta-5…rc-4 usable, an opt-in would be safer: only
pass `-Dmaven.mainClass` when the user explicitly sets e.g. `MVNW_MAIN_CLASS`,
instead of always. That preserves the escape hatch for the broken pre-releases
without pinning an internal Maven class name in perpetuity.
--
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]
