Skip to content

Add maven-classworlds module to replace plexus-classworlds dependency #11029

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Add maven-classworlds module to replace plexus-classworlds dependency #11029

wants to merge 1 commit into from

Conversation

gnodet
Copy link
Contributor

@gnodet gnodet commented Aug 7, 2025

  • 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

@gnodet gnodet force-pushed the feature/maven-classworlds-11028 branch 2 times, most recently from b820d27 to b4c6955 Compare August 9, 2025 13:39
@gnodet
Remove jline-native and JPMS support, extract org.apache.maven.api.cl…
fe2ac45 
…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 gnodet force-pushed the feature/maven-classworlds-11028 branch from b4c6955 to fe2ac45 Compare August 9, 2025 16:07
@cstamas
Copy link
Member

cstamas commented Aug 11, 2025

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?

@slawekjaranowski
Copy link
Member

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

@gnodet
Copy link
Contributor Author

gnodet commented Aug 12, 2025

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:

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 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@gnodet @cstamas @slawekjaranowski