-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
Enable JDK9+ module-info #519
Comments
First add a default module name, then later module info (a bigger job). |
This issue has been automatically marked as stale due to inactivity for 60 or more days. It will be closed in 7 days if no further activity occurs. |
Bump |
@skjolber now that 0.11.0 is out and builds/works on JDK 11, is this still needed? |
@lhazlewood can't seem to find any module descriptor or automatic module name entry in the manifest? Ref https://repo1.maven.org/maven2/io/jsonwebtoken/jjwt-impl/0.11.0/ |
@skjolber correct, we didn't add them to the release - I was curious however if they are still necessary to use in JDK11 given that our builds run and work on JDK11. |
So disabling the module system is possible, and then all will run 'as before'. But that is hardly proper support. You might be interested in this: https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers I have best experience with using the moditech plugin, see this example. |
Hi @lhazlewood. Is there a due date for the 0.12.0 milestone? |
@andrewhrytsiv Hi! All I can say as an unpaid team of volunteers, we move as quickly as we're able, so we cannot commit to any dates or timelines. I will say however that there has been a tremendous amount of active work in the last 3 months on the |
@lhazlewood I appreciate your work. Thank you for the feedback. |
@skjolber @lhazlewood I could create such a file using the moditect plugin if you are interested. WDYT? We would even still be Java 7 compatible if you needed that. |
@bmarwell that would be great! Any help here would be much appreciated. |
@lhazlewood I do have a local sketch-up now, but various things will fail. Or the call to this package-private constructor in another test: def decoder = new ExceptionPropagatingDecoder(new Decoder() { … } There are 42 (of course!) of those in the api project alone. Anyway, moditect is Java 8 and the jsonb-extension is also java8-only. That means that you wouldn’t be able to verify every feature using Java 7 anymore and release can only be done on Java 8 and above. I will look further into it, but I am still far away from creating a branch with helpful commits. |
… IT. - uses lots of more profiles - requires Java 8+ for a release - requires Java 9+ for running the integration test - does not deploy integration tests - maven.compiler.release is set instead of source and target for Java9+ - maven.compiler.source/target is now only set on Java7 and Java8 so the javadoc and sources plugin will work correctly. - Does not contain ITs for neither GSON nor org.json. - Ugly workaround for the fact that the old bundle-plugin crashes on Java9+ module-info.java files, had to provide an empty static MANIFEST.MF file and disable the bundle-plugin on ITs. - I found it odd that the extensions do not reference their correct parent pom as parent pom, instead the root is chosen. This is probably a maven anti-pattern and was corrected by khmarbaise for Shiro. - parentLocation = ../pom.xml is redundant for /api and /impl, but did not bother to correct it here - some pom.xml files were missing a final line break as required by unix spec.
@bmarwell makes sense. I'm fine waiting for 1.0 to introduce these changes. I don't want to cause any more churn than is necessary. |
I'm not sure why you guys made this more complex than it has to be. You just need to add a few lines to pom.xml to turn your releases into multirelease JAR files and you're done. Here is the code I lifted from https://medium.com/@ankitagrahari.rkgit/multi-release-functionality-8fc423b6c94e:
No need to mess around with Moditect or any 3rd-party plugin. Don't get me wrong, Moditect is a great plugin, but there is an easier way to get this done in this case... |
Yes, but back then it was probably necessary because jjwt did support very old Java versions (at least 7, maybe even 6) and needed to be compile on exactly java 8. Using MRJars would have meant introducing toolchains which is even more configuration compared to moditect which runs on 8. 😃 But yes,, the MR is now probably the better solution. |
@cowwoc JJWT still supports JDK 7, so if you'd like to open a PR that supports JDK 7 through 21, we'd appreciate it! 😉 |
@lhazlewood Sorry. No time at the moment... I'll revisit this eventually but it could be months away. |
… IT. - uses lots of more profiles - requires Java 8+ for a release - requires Java 9+ for running the integration test - does not deploy integration tests - maven.compiler.release is set instead of source and target for Java9+ - maven.compiler.source/target is now only set on Java7 and Java8 so the javadoc and sources plugin will work correctly. - Does not contain ITs for neither GSON nor org.json. - Ugly workaround for the fact that the old bundle-plugin crashes on Java9+ module-info.java files, had to provide an empty static MANIFEST.MF file and disable the bundle-plugin on ITs. - I found it odd that the extensions do not reference their correct parent pom as parent pom, instead the root is chosen. This is probably a maven anti-pattern and was corrected by khmarbaise for Shiro. - parentLocation = ../pom.xml is redundant for /api and /impl, but did not bother to correct it here - some pom.xml files were missing a final line break as required by unix spec.
I'm trying to use modules in a support library, but there seems to be no module-info for jjwt. I suggest following either Jackson's or SLF4J's approach.
The text was updated successfully, but these errors were encountered: