We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
I'm considering downgrading our support of JPMS (aka Java Modules) to that of automatic modules via a manifest declaration.
AFAIK Quarkus, Vert.x, Reactive Messaging and Hibernate Reactive are our most prominent downstream consumers, and none is using Java modules.
Also the ongoing efforts on #1330 show that consuming a library with neither a module descriptor nor an automatic module is complicated.
Thoughts?
The text was updated successfully, but these errors were encountered:
feat!: downgrade Java modules support to automatic modules
c99bf1d
Issue: #1406 BREAKING CHANGE: the Mutiny library is now exposed as an automatic module rather than a module with a module-info descriptor.
We won't go this way, we'll either have a JCTools release soon or we will use a fork.
The current JCTools master branch has a correct (generated) module-info that I've been able to test locally.
master
module-info
Sorry, something went wrong.
Successfully merging a pull request may close this issue.
I'm considering downgrading our support of JPMS (aka Java Modules) to that of automatic modules via a manifest declaration.
AFAIK Quarkus, Vert.x, Reactive Messaging and Hibernate Reactive are our most prominent downstream consumers, and none is using Java modules.
Also the ongoing efforts on #1330 show that consuming a library with neither a module descriptor nor an automatic module is complicated.
Thoughts?
The text was updated successfully, but these errors were encountered: