gradle puts module on the classpath

[dumischbaenger]

Hello,

I'm just about to migrate a legacy Java 8 application to java 11.

To be able to use Java modules I'm using extra-java-module-info to enrich old dependencies with module informations.

So I added this to buid.gradle:

extraJavaModuleInfo {
// failOnMissingModuleInfo.set(true)
automaticModule("jdbc-4.50.7.jar", "jdbc")
automaticModule("dom4j-1.6.1.jar", "dom4j")
automaticModule("table-layout-4.2.1.jar", "table.layout")
automaticModule("javax.mail-1.6.2.jar", "java.mail")
automaticModule("activation-1.1.jar", "activation")
automaticModule("jsch-0.1.55.jar", "jsch")
automaticModule("jFdfTk-1.0.0.jar", "jFdfTk")
}

This results in the following Compiler arguments:

2021-12-08T10:51:35.897+0100 [DEBUG] [org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler] Compiler arguments: -source 11 -target 11 -d /home/bdonauba/eclipse-config-2021-03/eclipse-workspace/reklam/build/classes/java/main -h /home/bdonauba/eclipse-config-2021-03/eclipse-workspace/reklam/build/generated/sources/headers/java/main -g -sourcepath /home/bdonauba/eclipse-config-2021-03/eclipse-workspace/reklam/src/main/java -proc:none -s /home/bdonauba/eclipse-config-2021-03/eclipse-workspace/reklam/build/generated/sources/annotationProcessor/java/main -XDuseUnsharedTable=true -classpath /home/bdonauba/.gradle/caches/transforms-3/38fe2cdbeab4466fe8b9ea86f83a7754/transformed/jFdfTk-1.0.0-module.jar --module-path /home/bdonauba/.gradle/caches/transforms-3/b701c2110ae391c40affb653f97f991e/transformed/dom4j-1.6.1-module.jar:/home/bdonauba/.gradle/caches/transforms-3/284c9a5db230fa29edbac12acaf2e18a/transformed/table-layout-4.2.1-module.jar:/home/bdonauba/.gradle/caches/transforms-3/6d8b5c1b60b80ffb6cf9c50a86cfe319/transformed/jdbc-4.50.7-module.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/com.sun.mail/javax.mail/1.6.2/935151eb71beff17a2ffac15dd80184a99a0514f/javax.mail-1.6.2.jar:/home/bdonauba/.gradle/caches/transforms-3/1dfbf89015ba4b32792bbcb0b0aed2b1/transformed/jsch-0.1.55-module.jar:/global/common/java/repo/com/tresorband/tooljava/1.0.0-202112070813/tooljava-1.0.0-202112070813.jar:/home/bdonauba/.gradle/caches/transforms-3/f8b36e4ea9d74e73e768e6f506f685bd/transformed/activation-1.1-module.jar /home/bdonauba/eclipse-config-2021-03/eclipse-workspace/reklam/src/main/java/module-info.java ...

As you can see every jar file is on the modulpath apart from jFdtTk. jFdtTk is on the classpath and therefore the compile fails. If I start javac in the bash and move jFdfTk-1.0.0-module.jar the modulepath javac suceeds.

[jjohannes]

That is weird and could be an issue in this plugin or in Gradle. Can you check the MANIFEST in jFdfTk-1.0.0-module.jar if it contains a valid "Automatic-Module-Name" entry? Maybe you can try using a different name than jFdfTk (if the name does not matter in this case).

[dumischbaenger]

MANIFEST.MF of jFdfTk-1.0.0-module.jar is empty.

[dumischbaenger]

Renaming the jar file was to no use. Appart from the missing manifest there is a second difference to the other jar files. This jar file is places in the libs directory of my project and is not fetched from Maven Central. Here are the relevant parts of my build.gradle file:

repositories {
  maven { url "file:///global/common/java/repo" }
  flatDir {
    dirs 'libs'
  }
  mavenCentral()
}

dependencies {
  implementation group: 'dom4j', name: 'dom4j', version: '1.6.1' exclude group: 'xml-apis'
  implementation group: 'info.clearthought', name: 'table-layout', version: '4.2.1' 
  implementation group: 'com.ibm.informix', name: 'jdbc', version: '4.50.7' exclude group: 'org.mongodb'
  implementation group: 'com.sun.mail', name: 'javax.mail', version: '1.6.2'
  implementation group: 'com.jcraft', name: 'jsch', version: '0.1.55'
  implementation group: 'com.adobe', name: 'xyz', version: '1.0.0'
  implementation group: 'com.tresorband', name: 'tooljava', version: '0.0.1'
}

extraJavaModuleInfo {
//  failOnMissingModuleInfo.set(true)
  automaticModule("jdbc-4.50.7.jar", "jdbc")
  automaticModule("dom4j-1.6.1.jar", "dom4j")
  automaticModule("table-layout-4.2.1.jar", "table.layout")
  automaticModule("javax.mail-1.6.2.jar", "java.mail")
  automaticModule("activation-1.1.jar", "activation")
  automaticModule("jsch-0.1.55.jar", "jsch")
  automaticModule("xyz-1.0.0.jar", "xyz")
  automaticModule("tooljava-1.0.0-202112070813.jar", "tooljava")
}

I attached my gradle.build and the debug log of the build.

gradle.log
build.gradle.txt

[jjohannes]

This jar file is places in the libs directory of my project

@dumischbaenger that explains it. The artifact transform mechanism of Gradle, which this plugin uses, does not trigger for "flatDir" repositories. It's generally discouraged to use these if you can.

There are two solutions I can think of:

1. Modify the Jar manually since it is under you control. Add a MANIFEST with the Automatic-Module-Name entry yourself and then you won't need to use this plugin for that Jar.
2. Turn the repository into a real repo:

maven { 
   url "lib" 
   metadataSources { artifact() } // with this Gradle will go directly for Jars (following the Maven naming schema) and will not look for POMs
}

Then you need to put your Jar into some folder that represents a "group" and "version", name it accordingly so that the file name includes the version, and address it by group/name/version when you define the dependency.

[dumischbaenger]

I added discarded my flatDir instruction and added the lib repository the way you suggested but that has led to same result. I've additionally added a manifest file with the Automatic-Module-Name property and after that it worked.

I don't know why the change from flatDir to maven was not sufficient. If your interested in further investigation I'd like to assist otherwise you can close this issue.

[dumischbaenger]

I've forgot the most important: Thank you for your support!

[jjohannes]

Alright. Then my memory was wrong. I think that means that the artifact transforms only work if you have propert metadata for the component. So you could add a simple pom.xml to your local repo to make it work (and not do the metadataSources { artifact() } bit)

No worries @dumischbaenger. Happy you got this working for you.