Add Automatic-Module-Name to package

[GedMarc]

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

Please make a module name :)

[johnjaylward]

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

[GedMarc]

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]

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

[johnjaylward]

@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]

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]

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]

100% 👍

[BGehrels]

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]

@BGehrels 20180813 is ready in both repos, thanks!

[GedMarc]

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

[BGehrels]

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

[GedMarc]

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

[BGehrels]

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

[GedMarc]

Hmm, nope