Great! This was a new exception for me. Very good to see that the plugin
does its job as expected.
cheers,
Robert
On Sun, 03 Dec 2017 15:31:37 +0100, Ceki Gulcu <c...@qos.ch> wrote:
Hi Robert,
I found running the command
mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve \
-DexcludeTransitive
to be highly informative. Thank you.
Apparently, there were issues in the way I edited MANIFEST.MF file in
groovy-2.4.13.jar. I won't bore you with the details. Anyhow, I reverted
to the original jar file, ran m-dependency-p and got:
Can't extract module name from groovy-2.4.13.jar: Provider class groovy
not in module
After some investigation, it appeared that this is due to the contents
of the file
META-INF/services/org.codehaus.groovy.source.Extensions
Removing this file solves the problem at least as far as Jigsaw module
resolution is concerned. Running m-dependency-p, I see:
o.c.groovy:groovy:jar:2.4.13:compile (optional) -- module groovy (auto)
Again, thank you very much for your help,
--
Ceki
On 03.12.2017 14:06, Robert Scholte wrote:
On Sun, 03 Dec 2017 13:40:51 +0100, Ceki Gulcu <c...@qos.ch> wrote:
Hello all,
The logback project, more specifically logback-classic, offers the
possibility of configuration via a script written in Groovy. Thus,
logback-classic has source files written in Java and a few source
files in Groovy.
While attempting to (Jigsaw) modularize the logback project, I first
tried to declare "requires static groovy" in logback-classic's
module-info.java file but the compiler was unable to load
groovy-2.4.13.jar as an auto-module.
To get the ball rolling, I had to resort to the "--add-reads
ch.qos.logback.classic=ALL-UNNAMED" compiler directive. This is very
unsatisfactory.
On twitter, Cédric Champeau suggested manually editing MANIFEST.MF in
groovy-2.4.13.jar adding "Automatic-Module-Name: groovylang". I edited
the file and also declared "requires static groovylang" in
logback-classic's module-info.java. However, this did not help and I
still get "module not found: groovylang"
Building with maven's -X option, I see that groovy-2.4.13.jar ends up
on the compiler's class path instead of the module path.
Still on twitter, Robert Scolte responded that m-compiler-p only puts
the jars on the module path if they are referred to by a requires
statement anywhere in the module descriptors tree. The rest ends up on
the classpath.
I am assuming here that "module descriptors tree" refers to
module-info.java files and not dependency declarations in pom.xml
files. Thus, if I understand correctly m-compiler-p parses
module-info.java files before invoking javac. Really?
Yes, really. In fact it goes beyond that. It also parses
module-info.class, reads the MANIFEST.MF for Automatic-Module-Name and
uses some specific Java9 code to extract the automatic module name from
the jarfile.
The code for this can be found at
https://github.com/codehaus-plexus/plexus-languages/tree/master/plexus-java
If you want to know the module names per jar, please run (with
JAVA_HOME pointing to /path/to/java9):
mvn compile
org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve
-DexcludeTransitive
thanks,
Robert
Best regards,
-- Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
