Add maven-classworlds module to replace plexus-classworlds dependency
- Copy complete plexus-classworlds source code to impl/maven-classworlds
- Replace all plexus-classworlds dependencies with maven-classworlds
- Update module structure and assembly configuration
- Maintain original package structure for now
- All builds passing
Implements first step of issue #11028
Should we maybe at the same time archive/EOL plexus-classworlds? Also, is this a fork of it? Or rewrite? As if some third-party may use plexus-classworlds, is this new module drop in replacement?
I'm not sure if we need copy it to Maven core ...
Why not simply update plexus-classworlds?
Especially that old java package and old licenses header are preserved
Should we maybe at the same time archive/EOL plexus-classworlds? Also, is this a fork of it? Or rewrite? As if some third-party may use plexus-classworlds, is this new module drop in replacement?
This is currently a fork, and I removed the old layer already.
I'm not sure if we need copy it to Maven core ... Why not simply update
plexus-classworlds?Especially that old java package and old licenses header are preserved
This was really a first step. I was toying a bit to solve a few limitations:
- clean integration within the Maven 4 API
- enable JPMS to load some bits of maven-core (in particular JLine to get rid of the
--enable-native-access=ALL-UNNAMED) - better plugin class loader customisation (https://github.com/apache/maven/issues/8960, not started)
- enable JPMS-enabled plugins (haven't really given that much thoughts)
One important point is that extensions should be able to provide controlled access to some API, which could be consumed by plugins. Plugins themselves could export some packages, I think we had some use cases for that (we currently need an extension to do that).
So not sure yet, this is just experiments... but ideas welcomed. Overall, I think plexus-classworlds won't be able to solve the above problems, and given Maven is really the only user afaik, I'm tempted to merge ...