Automatic module names

[Brian Fox]

In my mind, proposal 2 (eliminating automobiles) is infinitely preferable
to what we have today.

The one downside as compared to leveraging the existing coordinates
(proposal 1) is that it doesn't do anything to set a best practice in what
good names look like. If nothing else, the maven coordinates are usually
the same as the existing package structure because of the fqdn roots in the
groupid and are at least unlikely to conflict with someone else.

On Mon, Jan 30, 2017 at 10:26 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> So far I haven't commented on automatic modules because while I don't see
> them as useful, I also didn't see them as harmful.  However this keeps
> popping up, so, see inline comments.
>
> On 01/27/2017 08:11 AM, Stephen Colebourne wrote:
> [...]
>
>> The issue is clear. If I write this:
>>
>> module org.joda.convert {
>>   requires guava;
>> }
>>
>> where guava is an automatic module, I am locking in the name of the
>> guava dependency, something that I do not control. The name "guava" is
>> just a guess. The guava authors might choose "com.google.guava" or
>> something else entirely.
>>
> [...]
>
>> In a closed system of modules, ie. a private application, automatic
>> modules are fine, because the requires clause can be changed if it
>> turns out the guess was wrong. But once published as an open source
>> project to Maven Central or elsewhere, the guess cannot be fixed if it
>> is wrong (without releasing a new version of the library, which is not
>> an acceptable solution).
>>
> [...]
>
> - Remove the automatic module concept altogether
>>
>
> This is my vote.  Automatic modules are meant to simplify migration by
> allowing "legacy" artifacts to be included in a modular environment. But in
> real use cases, it is often if not usually the case that manual
> intervention will be required anyway.  Therefore, automatic modules do not
> actually make things any easier (in fact they hide land mines around your
> deployment operation).  It makes more sense to create or use a provided
> tool to easily modularize a JAR by allowing its dependencies to be
> specified.  A system like Maven might allow such a modularization process
> to be largely automatic, thanks to the dependency information already at
> its disposal (though such a case *should* present a report to the user
> allowing them to spot any problems or potential problems that may arise
> from a particular generated wiring; in general, magic is bad if it isn't
> well-defined or easily validated).
>
> As I've expounded on previously, on multiple occasions, it is highly
> unlikely that centrally deployed modules will be universally useful without
> manual work on the part of the consumer.  It is far better to make this
> process as clean, easy, and well-defined as possible than to "fudge" it
> using automatic modules, magical wiring, or anything else of the sort,
> which seems easy at first and then bites back later.
>
> Given that applications can depend on libraries that haven't been
>> released in years, this has the potential to be a critical problem for
>> the ecosystem. My preference remains to define a clear mapping from
>> the widely adopted Maven Central naming strategy to JPMS modules.
>>
>
> This could be very useful.  But I think it should be a Maven function
> rather than adding this to the JPMS, forever.
>
> --
> - DML
>