gnodet commented on PR #13277:
URL: https://github.com/apache/maven/pull/13277#issuecomment-5874487419
The right direction here is to use ClassWorlds realms directly, which is
exactly what the existing infrastructure was designed for.
Rather than a custom `URLClassLoader` dispatch mechanism, define a dedicated
realm in `m2.conf` for each tool that has tool-specific dependencies:
```
[plexus.core]
load ${maven.conf}/logging
...
load ${maven.home}/lib/maven-*.jar
load ${maven.home}/lib/*.jar
[plexus.mvnup]
import org.apache.maven from plexus.core
import org.codehaus.plexus from plexus.core
import org.slf4j from plexus.core
optionally ${maven.home}/lib/mvnup/*.jar
```
Then `MavenUpCling` asks the `ClassWorld` for `plexus.mvnup` instead of
`plexus.core`, and builds its DI container from that realm. Domtrip jars go in
`lib/mvnup/` and are never visible to the build engine. No new discovery
protocol, no custom classloader code — just the existing ClassWorlds machinery.
All realm sections in `m2.conf` are parsed unconditionally at startup, but
with `optionally` the directory scan is a no-op if the dir doesn't exist, and
the DI container for the tool realm is only spun up when the tool is actually
invoked. So the overhead for a plain `mvn build` is negligible.
This is the concrete path forward: close this PR and open a new one that
moves `mvnup`'s dependencies (`domtrip-core`, `domtrip-maven`) to `lib/mvnup/`
with a `plexus.mvnup` realm in `m2.conf`.
--
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]
