slachiewicz commented on issue #1795: URL: https://github.com/apache/maven-mvnd/issues/1795#issuecomment-6170948865
Why the relocation matters: the daemon starts as `java -classpath plexus-classworlds.jar -javaagent:mvnd-agent.jar`, so the agent jar and its bundled javassist sit on the system class loader. Maven uses that loader as the parent of every plugin and extension realm (`DefaultClassRealmManager.PARENT_CLASSLOADER = ClassWorld.class.getClassLoader()`, on both master and maven-3.9.x). A plugin that bundles javassist still gets its own copy, because realms look in their own jars first. A plugin that doesn't bundle it, or that probes for it with `Class.forName`, finds javassist 3.33 under mvnd but not under `mvn`. #1807 (master) and #1833 (`mvnd-1.x`) relocate it to `org.mvndaemon.mvnd.shaded.javassist`. The text javassist compiles into `ProcessBuilder` names no javassist classes, and shade also rewrites javassist's own by-name references (`javassist.runtime.*`). `minimizeJar` must stay off, because it can't see classes javassist loads by name. Verified: `./mvnw -pl agent -am package` on both branches → no overlapping-classes warning, no top-level `javassist/` entries, and `Agent$1` references the relocated classes. No other daemon-added dependency leaks to plugins on master. On `mvnd-1.x`, `mvnd-daemon`'s `META-INF/maven/extension.xml` also exports `org.apache.commons.logging.*` (jcl-over-slf4j, #183) and plexus-interactivity. Both are deliberate, and master dropped them when it moved to Maven 4. Alternatives considered, none worth doing now: - **Isolated class loader inside the agent:** the same isolation as relocation, with more code. - **ASM instead of javassist:** still needs shading, and replaces a 9-line source snippet with hand-written bytecode. - **JDK ClassFile API (JEP 484):** no dependency at all, but it needs Java 24 and the build targets 17. Worth revisiting when the floor moves. - **Native redirection via `mvnd-native`** (`dup2` on Unix, `SetStdHandle` on Windows, for the duration of a build): a daemon runs one build at a time, and `EnvHelper` already uses JNI `setenv` and `chdir` per build. This would remove javassist, the agent and the helper jar, and would also capture native-code output. It is open whether output from parallel (`-T`) builds can be attributed to the right module. Platforms without the native library would also need a fallback. That deserves its own issue if anyone wants to pursue it. -- 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]
