Automatic module names

[David M. Lloyd]

On 02/03/2017 09:40 AM, Alan Bateman wrote:
> On 03/02/2017 11:44, Robert Scholte wrote:
>
>> Hi Nicolai,
>>
>> let's consider that my project depends on the following dependencies:
>> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
>>
>> I somehow want to have them both as requirements:
>> module M.N {
>>   requires static library; // com.foo.bar:library
>>   requires library; // com.acme:library
>> }
>>
>> How can I define that the 'requires static library' should be mapped
>> to com.foo.bar:library:1.0 on the modulepath, while 'requires library'
>> should be mapped to com.acme:library:2.3.1
>>
>> One ugly solution would be:
>>   requires static library containing com.foo.bar.baz.SomeClass;
>>   requires library containing acme.AnotherClass;
>>
>> We should really wonder if ease-of-transition is worth the minefield
>> we're creating with the introduction of automodules. IMHO all options
>> we're trying to add to keep automodules will only over-complicate
>> things, not even being sure if all edges are covered.
> I think automatic modules are critical to migration, otherwise things
> move at the pace of the slowest project (which might be 0km/h in case of
> unmaintained projects). A lot of the discussion here has been on the
> naming but automatic modules but the other important benefit of
> automatic modules is that they support bridging to the class path.

I still believe this conclusion is based on a false assumption, or 
rather a pair of them: the assumption that users will generally wish to 
distribute a module as a direct artifact of their build in any cases but 
the most proprietary, and the assumption that modularizing a project is 
something that is done when that project is compiled rather than when it 
is distributed.  All evidence seems to indicate that these assumptions 
are completely unfounded.

Using tooling to migrate to a modularized environment is not only a 
perfectly reasonable alternative, but is very, *very* likely to be quite 
close to the standard build/distribute workflow coming out the gate and 
onward for many years.  Maven and Gradle essentially dominate the world 
of Java project building.  They (and their supporting utilities) already 
take on most if not all distribution tasks: customizing MANIFEST.MF and 
service files, bundling local and even remote resources, source and 
bytecode translation, annotation processing, customized packaging, etc. 
It seems inevitable that such tools will also be used build module 
distributions, performing resolution and wiring tasks on large groups of 
artifacts at a time and producing a module set or even an image at 
output, as a final step before CI and/or distribution.  I cannot 
conceive of any other sane workflow unless as I said your environment is 
highly proprietary (neither consuming nor producing artifacts that are 
ever shared with anyone else nor shared across distibution-wide 
versions) and/or highly constrained (to a very small number of modules 
or using very rigid (and probably brittle) rules for artifact sharing). 
Note that in these cases, most if not all of the value proposition of 
modularity is already lost.

> As regards the example naming clash then these two projects might
> already get complaints over their poor choice of artifacts, esp. when
> artifacts for both projects are in same directory (say where someone
> distributes with all JAR files in a `lib` directory).

-- 
- DML