[
https://issues.apache.org/jira/browse/MJLINK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16710620#comment-16710620
]
Gili commented on MJLINK-27:
----------------------------
[~rfscholte] Attached. I am expecting three things:
1. Consist ordering rules throughout all Maven plugins (e.g. compiler, jlink,
etc): if the compiler will be passed modules in the same order mentioned by
<dependency> then I expect the first plugin to always win.
2. The same pom.xml file should always result in the same build/runtime
behavior (deterministic behavior). If you guys are using HashMap or some other
collection that does not guarantee order, we run the risk of getting a
different modulepath ordering at every run.
3. Swapping the order of the dependencies should result in main() outputting
"the other" plugin. So if you used to get "plugin1" as output, swapping
dependencies should result in "plugin2" getting output.
> 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)
