You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "b. ohnsorg (Jira)" <ji...@apache.org> on 2020/06/29 15:59:00 UTC
[jira] [Comment Edited] (MJDEPS-20) jdeps for modularized code
should use --module-path
[ https://issues.apache.org/jira/browse/MJDEPS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147908#comment-17147908 ]
b. ohnsorg edited comment on MJDEPS-20 at 6/29/20, 3:58 PM:
------------------------------------------------------------
From time to time I run into this issue and it is annoying enough so I had a look at the code. Basically I know what to do to push the classpath-resources into a new command option. I'm only uncertain how to derive it from runtime environment.
I can think of at least two options: double -cp and put all the elements from classpath into module-path, too. Another option would be a <dependency>-structure, explictely configuring which modules to take into consideration. This could also be some sort of include/ exclude-thing to filter classpath-elements. Then the filtered list is put into module-path-option.
I often stumble across this with modularized projects, looking like this:
{code:java}
/-pom.xml: root with all modules/ packaging=pom
|- assets: not containing anything relevant for the Maven-portion of this project
|- <name>-app/pom.xml: binding all the tiny bits into a deliverable
|- <name>-config/pom.xml: configuration module, constants, loading preferences
|- <name>-api/pom.xml: pure contracting, only interfaces
|- <name>-model/pom.xml: model elements/ transfer objects
|- <name>-ui/pom.xml: ui-components
{code}
Such projects often build the dependency chain like:
{code:java}
api <- model
config <- ui
model <- ui
ui <- app{code}
Thus I'd be comfortable with for example ui's pom.xml to have a jdeps-config like the following (where <name> is replaced with something like foobar, e.g. foobar-ui, foobar-model etc.):
{code:java}
<plugin>
<configuration>
<modulePathInclude>foobar*</modulePathInclude>
</configuration>
</plugin> {code}
Which in turn would copy all classpath-elements matching this filter to the module-path-argument.
(?) Is it necessary to remove those elements from the -cp argument then?
was (Author: b.ohnsorg):
From time to time I run into this issue and it is annoying enough so I had a look at the code. Basically I know what to do to push the classpath-resources into a new command option. I'm only uncertain how to derive it from runtime environment.
I can think of at least two options: double -cp and put all the elements from classpath into module-path, too. Another option would be a <dependency>-structure, explictely configuring which modules to take into consideration. This could also be some sort of include-/ exclude-thing to filter classpath-elements. Then the filtered list is put into module-path-option.
I often stumble across this with modularized projects, looking like this:
{code:java}
/-pom.xml: root with all modules/ packaging=pom
|- assets: not containing anything relevant for the Maven-portion of this project
|- <name>-app/pom.xml: binding all the tiny bits into a deliverable
|- <name>-config/pom.xml: configuration module, constants, loading preferences
|- <name>-api/pom.xml: pure contracting, only interfaces
|- <name>-model/pom.xml: model elements/ transfer objects
|- <name>-ui/pom.xml: ui-components
{code}
Such projects often build the dependency chain like:
{code:java}
api <- model
config <- ui
model <- ui
ui <- app{code}
Thus I'd be comfortable with for example ui's pom.xml to have a jdeps-config like the following (where <name> is replaced with something like foobar, e.g. foobar-ui, foobar-model etc.):
{code:java}
<plugin>
<configuration>
<modulePathInclude>foobar*</modulePathInclude>
</configuration>
</plugin> {code}
Which in turn would copy all classpath-elements matching this filter to the module-path-argument.
(?) Is it necessary to remove those elements from the -cp argument then?
> jdeps for modularized code should use --module-path
> ---------------------------------------------------
>
> Key: MJDEPS-20
> URL: https://issues.apache.org/jira/browse/MJDEPS-20
> Project: Maven JDeps Plugin
> Issue Type: Bug
> Affects Versions: 3.1.2
> Reporter: Andre Tadeu de Carvalho
> Priority: Major
>
> In the attempt to solve https://issues.apache.org/jira/browse/MJDEPS-16, I discover that the plugin is not settings *--module-path* when the code is modularized. It also need to set the target to _target/classes/module-info.class_ instead _target/classes_.
> As an example in [https://github.com/andretadeu/maven-jdeps-plugin.git,] branch MJDEPS-16, running the test *MJDEPS-16_jdkinternals*:
> {code}
> jdeps --module-path <local repo>/com/google/inject/guice/4.2.0/guice-4.2.0.jar:<local repo>/javax/inject/javax.inject/1/javax.inject-1.jar:<local repo>/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:<local repo>/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar:<local repo>/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:<local repo>/org/checkerframework/checker-qual/2.0.0/checker-qual-2.0.0.jar:<local repo>/com/google/errorprone/error_prone_annotations/2.1.3/error_prone_annotations-2.1.3.jar:<local repo>/com/google/j2objc/j2objc-annotations/1.1/j2objc-annotations-1.1.jar:<local repo>/org/codehaus/mojo/animal-sniffer-annotations/1.14/animal-sniffer-annotations-1.14.jar -jdkinternals <Project root>/target/it/MJDEPS-16_jdkinternals/target/classes/module-info.class
> {code}
> should return:
> {code:java}
> com.google.common automatic
> [file:///home/andre/workspaces/oss/maven-jdeps-plugin/target/local-repo/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar]
> requires mandated java.base
> com.google.common -> jdk.unsupported
> com.google.common.cache.Striped64 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.cache.Striped64$1 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.cache.Striped64$Cell -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$1 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$2 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$3 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.Striped64 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.Striped64$1 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.hash.Striped64$Cell -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator$1 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper$1 -> sun.misc.Unsafe JDK internal API (jdk.unsupported)
> Warning: JDK internal APIs are unsupported and private to JDK implementation that are
> subject to be removed or changed incompatibly and could break your application.
> Please modify your code to eliminate dependence on any JDK internal APIs.
> For the most recent update on JDK internal API replacements, please check:
> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> JDK Internal API Suggested Replacement
> ---------------- ---------------------
> sun.misc.Unsafe See http://openjdk.java.net/jeps/260
> {code}
> If the code is not modularized, it should keep using *-cp* instead of *--module-path* and it will point to _target/classes**_. If jdeps command is using *--module-path*, it should point to *module-info.class*, or the command won't return a single line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)