Re: [PR] Support Maven 4 by setting maven.mainClass to MavenCling [maven-wrapper]

["ascheman (via GitHub)" <gi...@apache.org>]

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: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org