Add maven-classworlds module to replace plexus-classworlds dependency#11029
Add maven-classworlds module to replace plexus-classworlds dependency#11029gnodet wants to merge 1 commit intoapache:masterfrom
Conversation
gnodet
force-pushed
the
feature/maven-classworlds-11028
branch
2 times, most recently
from
b820d27 to
b4c6955
Compare
…assworld to separate API module - Remove jline-native references from Maven launcher scripts (mvn and mvn.cmd) - Remove jline-native dependencies and configurations from POMs - Remove module-info.java file from maven-classworlds - Remove jline-native assembly configurations and README - Create new maven-api-classworlds module in api/ directory - Move org.apache.maven.api.classworlds package to new API module - Update dependency management and module references - Add maven-api-classworlds dependency to modules that use the API This change separates the public API from the implementation, following Maven 4 architecture patterns, and removes the JPMS and jline-native dependencies that were causing complexity in the build and runtime environment.
gnodet
force-pushed
the
feature/maven-classworlds-11028
branch
from
b4c6955 to
fe2ac45
Compare
|
Should we maybe at the same time archive/EOL plexus-classworlds? |
|
I'm not sure if we need copy it to Maven core ... Especially that old java package and old licenses header are preserved |
This is currently a fork, and I removed the old layer already.
This was really a first step. I was toying a bit to solve a few limitations:
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 |
3 participants
Implements first step of issue #11028