RFE regarding duplicate module message

[Paul Benedict]

Thanks Alan. After sending my original message, I realized even listing out
names could be confusing if not given proper context. It's so easy to
forget that an exploded module directory name has *nothing* to do with the
actual module name. Thus, a message showing "[com.domain1, com.domain2,
com.domain3]" can be misleading. The message should be very clear that
what's being displayed are paths to module directories (not the names of
modules). This is where the user needs to go to find the erring metadata.
Example: "[mods/com.domain1, mods/com.domain2, mods/com.domain3]"

In your opinion, should anything be done to enforce alignment between the
exploded module directory name and the module name? I know the directory is
just a name, but it's an easy trap to fall into. The compiler requires
exploded packages on the file system to be in identically named directory;
so why not exploded modules?

In my opinion, it may be worth exploring alignment between exploded module
directory names and the module name found within. Following the example of
the SOTMS [1], should "mods/com.greetings" always have a "com.greetings"
module inside of it?

[1] http://openjdk.java.net/projects/jigsaw/quick-start

Cheers,
Paul

On Mon, Jul 11, 2016 at 4:32 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 11/07/2016 19:48, Paul Benedict wrote:
>
> Regarding this exception:
>> java.lang.module.ResolutionException: Two versions of module com.domain2
>> found in mods
>>
>> I have three requests:
>>
>> 1) The "two versions" is actually misleading. In my system, I purposely
>> created three "com.domain2" in my modules directory. It's better to just
>> say there is a "duplicate" module than specify a number.
>>
>> 2) Can the clashing modules be listed out please? Which ones in the module
>> path are the offenders?
>>
>> 3) Just as "com.domain2" was called out as a "module" in the message,
>> please also refer to "mods" as the module path.
>>
>> Thanks for the mail. I think we can improve the message to make it
> clearer which artifacts have the duplicate module. There are a number of
> patches coming to the module path that change this code a bit but I can we
> can easily include this.
>
> -Alan
>