gnodet commented on PR #13277: URL: https://github.com/apache/maven/pull/13277#issuecomment-5901328193
Let me clarify why CLAPP cannot solve the dependency isolation problem for `mvnup` as it currently stands. `mvnup`'s goal classes (`SourceStrategy`, `ModelUpgradeStrategy`, `StrategyOrchestrator`, etc.) are Maven DI components — annotated with `@Named`/`@Singleton` from `org.apache.maven.api.di` and discovered via `InjectorImpl.discover(ClassLoader)`, which reads `META-INF/maven/org.apache.maven.api.di.Inject` from the `plexus.core` realm and loads component classes directly from it. Those component classes reference domtrip types in their method signatures and field declarations, so domtrip must be loadable from the same `plexus.core` classloader. CLAPP's child `URLClassLoader` is only in play for the reflective entry-point dispatch — it never participates in DI container bootstrap. The container is built from `plexus.core` directly, and CLAPP has no mechanism to inject additional URLs into that realm. So the claim that CLAPP "isolates domtrip from the main Maven classpath while preserving full compatibility" is not correct for `mvnup` as it stands today. If you believe CLAPP is the right solution, the way to validate it is to actually refactor `mvnup` to use it — i.e. make the `mvnup` goals no longer DI-managed components discovered from `plexus.core`, but instead plain classes loaded from the CLAPP child loader and invoked directly. That would be a significant redesign of `mvnup`, and it would demonstrate concretely that the mechanism works. Until that is done, this PR adds infrastructure for a problem it cannot actually solve. -- 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]
