[Commented] (MJLINK-27) Code incorrectly assumes that two modules won't have the same name

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Commented] (MJLINK-27) Code incorrectly assumes that two modules won't have the same name

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/MJLINK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711888#comment-16711888 ]

Robert Scholte commented on MJLINK-27:
--------------------------------------

bq. the actual output by maven-jlink-plugin is correct.

This is what I would expect.

bq. In spite of the aforementioned bug in getModulePathElements(), which still needs to be fixed.

The current result is by design. plexus-java has the option to divide path elements over the modulepath and classpath. It walks through the tree of all required modules, but this only works if it knows which modules are in the end selected by the JRE, hence it already picks the first module in case there are multiple with the same name.
All required information is available in the [ResolvePathsResult|https://codehaus-plexus.github.io/plexus-languages/plexus-java/apidocs/org/codehaus/plexus/languages/java/jpms/ResolvePathsResult.html]. The lazy solution would be to simple put all {{pathElements()}} on the modulepath, but why?
If you want to include all modules with name X, you need to add a setter to the request ( e.g. setAllowDuplicateModules() ) and adjust the implementation.

> Code incorrectly assumes that two modules won't have the same name
> ------------------------------------------------------------------
>
>                 Key: MJLINK-27
>                 URL: https://issues.apache.org/jira/browse/MJLINK-27
>             Project: Maven JLink Plugin
>          Issue Type: Bug
>    Affects Versions: 3.0.0-alpha-2
>            Reporter: Gili
>            Priority: Major
>         Attachments: module-shadowing.zip
>
>
> Karl Heinz Marbaise closed MJLINK-7 referencing [a Stackoverflow post|https://stackoverflow.com/questions/46573572/java-9-possible-to-have-2-modules-with-same-name-on-module-path/46574200#46574200] to prove that module names must be unique. In fact, this Stackoverflow post says the exact opposite. The bottom half of the post states that modules in separate directories **are** allowed to have the same name. The bottom of the post concludes:
> {quote}That makes it possible to have the same module in different directories.
> {quote}
> It doesn't have to be the same module per-se. It is possible for two different implementations with the same module name to reside on the module path, so long as the modules reside in different directory. This is useful for "class shadowing". In my particular case, I ship a no-op implementation of a module by default but users can insert a working implementation in front of the module path to enable the feature.
> Please reopen this issue or continue its work here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)