Skip to content
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

Add Automatic-Module-Name to package #431

Closed
GedMarc opened this issue Aug 13, 2018 · 19 comments
Closed

Add Automatic-Module-Name to package #431

GedMarc opened this issue Aug 13, 2018 · 19 comments

Comments

@GedMarc
Copy link

GedMarc commented Aug 13, 2018

Getting warnings when deploying to central that there are filename based references (requires json) :)

Please make a module name :)

@johnjaylward
Copy link
Contributor

johnjaylward commented Aug 13, 2018

Can you provide more information? I'm not sure what you are talking about.

@GedMarc
Copy link
Author

GedMarc commented Aug 13, 2018

When using on JDK 9 or above, the module name is automated to the filename "json". Using a proper module-name needs to happen :)
When taking this and deploying to maven central the following error is noted :

  • Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *

This can be solved properly by adding the following line into the Manifest.MF file
Automatic-Module-Name: org.json

There are two possible ways for an automatic module to get its name:
When an Automatic-Module-Name entry is available in the manifest, its value is the name of the automatic module
Otherwise, a name is derived from the JAR filename (see the ModuleFinder JavaDoc for the derivation algorithm)
See here :
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html <- the explanation of module hell problem

@johnjaylward
Copy link
Contributor

johnjaylward commented Aug 13, 2018

Thanks, I'll take a look, but at a brief glance, this will probably affect our package maintainer @BGehrels

johnjaylward added a commit to johnjaylward/JSON-java that referenced this issue Aug 13, 2018
@johnjaylward
Copy link
Contributor

@BGehrels the Practical Tips section of this page should do what we need to java9 modules support: https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers

Adding in module-info.java really isn't useful at this time since older compilers won't know what to do with a module class type.

@GedMarc
Copy link
Author

GedMarc commented Aug 13, 2018

There are a few ways to do this, I recommended what I thought would be the best approach with least impact,

To build the module-info and not change anything and only update your project - the moditect (https://github.com/moditect/moditect) project does precisely this compatible with jdk 7 I believe. Used in quite a few places successfully (look at classgraph)

Other ways include

  1. Go automatic-module-name and keep current build/compile structure with minimum impact
  2. Go versions route, where you compile the classes into META-INF/versions/9 or 8 or 10 or 11
  3. Go dual build and have two artifacts for jre 8 and jre 10 (best way for service loader support) where jre 10 will contain the module-info.java class

I do recommend moditect without changing the codebase if you do want a module-info.java class file in a jre7/8 library.

@johnjaylward
Copy link
Contributor

We are currently compiling to jdk6 to leave support for some older embedded systems that don't allow updates to the JVM. Using the gradle/maven support to modify the manifest seems like the easiest solution at the moment to me. Adding in extra dependencies just for building is usually a bad idea for such simple projects as this. We have only a single module package to export, and we have no external dependencies, so updating the MANIFEST.MF to contain Automatic-Module-Name: org.json is the simplest solution. I don't see any reason to dual/multi build for this.

@GedMarc
Copy link
Author

GedMarc commented Aug 13, 2018

100% 👍

@BGehrels
Copy link
Contributor

Ready when you are, pom changes are implemented, all i'll need is a git tag here and in the test repo (with identical names)

@stleary
Copy link
Owner

stleary commented Aug 14, 2018

@BGehrels 20180813 is ready in both repos, thanks!

@GedMarc
Copy link
Author

GedMarc commented Aug 14, 2018

Doesn't look like it's synced to central :)

@BGehrels
Copy link
Contributor

just built the release, should be synced to cenetral in the next hour

@GedMarc
Copy link
Author

GedMarc commented Aug 14, 2018

hmm, taking forever to sync
https://mvnrepository.com/artifact/org.json/json

@BGehrels
Copy link
Contributor

Oops, yes, forgot to press one magic button, should work soon

@GedMarc
Copy link
Author

GedMarc commented Aug 15, 2018

Hmm, nope

@johnjaylward
Copy link
Contributor

@GedMarc
Copy link
Author

GedMarc commented Aug 15, 2018

yeah just maven central web sites not updated, 100%

@GedMarc GedMarc closed this as completed Aug 15, 2018
@GedMarc
Copy link
Author

GedMarc commented Aug 15, 2018

THANKSSSS!!!!!

much love

@A-Ghost
Copy link

A-Ghost commented Sep 10, 2018

I would suggest you look at the class versioning system introduced in Java 9(META-INF/versions/9) to add the module-info.java file because it actually does serve a purpose. Notably jlink won't be able to create images with this library because it can't use automatic modules even if they have a fixed name. This is unfortunately a problem I'm running into and the only fix is for me to recompile the sources from git with my own module-info.java file

@johnjaylward
Copy link
Contributor

@A-Ghost do you have a quick how-to or other document you can link to with an overview of the feature? When I looked, I didn't see a nice way to include a module-info.java file and still have it compile down to java6.

Or better yet, can you offer a pull request that would accomplish this? Java6 is still a requirement for this project at this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants