Open sandermak opened 6 years ago
com.graphaware.neo4j:graphaware-framework-embedded:3.4.6.52
-> org.objectweb.asm
io.wizzie:normalizer-service:0.6.1.1
-> org.slf4j
org.checkerframework.annotatedlib:guava:26.0-jre
-> com.google.common
More examples, partly fixed in more recent versions, https://github.com/jodastephen/jpms-module-names/issues/16
Shading tools should prevent copying module-info.class
files by default: https://github.com/johnrengelman/shadow/issues/352
Perhaps we should check for the properties of a "well-named" module listed here: http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
Looking at org.checkerframework.annotatedlib
, it is positioned as a 'better' annotated version of Guava. The checkerframework docs tell users to just replace their original Maven dep with the annotated version (https://checkerframework.org/manual/#annotated-libraries-using). So in that sense, exposing it with the original (automatic) module name seems legit.
The other two are definitely not ok.
FYI, jodastephen/jpms-module-names is superseded by https://github.com/sormuras/modules
Initial scan results show several JARs that are either classified as automatic module or explicit module, because they shade another JARs that has a
module-info.class
descriptor orMANIFEST.MF
file. These should ideally not be counted as automatic or explicit modules. Even better, this situation should be flagged so that library maintainers can resolve this, because this will break their library on the module path.