Revised proposal for #AutomaticModuleNames

[Remi Forax]

Hi Robert,

----- Mail original -----
> De: "Robert Scholte" <rfscholte at apache.org>
> À: "mark reinhold" <mark.reinhold at oracle.com>
> Cc: jigsaw-dev at openjdk.java.net
> Envoyé: Vendredi 5 Mai 2017 12:04:15
> Objet: Re: Revised proposal for #AutomaticModuleNames

> Hi Mark,
> 
> thanks for these adjustments. In general they look good, but it all
> depends on the details:
> 
>     Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose
>     value is used as the name of the automatic module defined by that JAR
>     file when it is placed on the module path, as previously suggested
>     [2][3].  If a JAR file on the module path does not have such a
>     manifest attribute then its automatic-module name is computed using
>     the existing filename-based algorithm.
> 
> Just to be clear: does this make it an auto module? In that case we're
> still a bit stuck, because I still insist that jars published to any
> public artifact repository should never refer to an automodule. Published
> jars with this attribute should have received this name by their developer
> and this also implies that the jar is Jigsaw-ready, e.g. no more split
> packages. In the future its users should be able to switch to the fully
> modular jar with the same name without any problem. So I need an extra
> state, e.g. isAutomatic() + isNamed(), in which case I have to change my
> insisting line: "Never publish jars to any public artifact repository that
> refers to *unnamed* automatic modules".

yes, knowing if the name is auto-calculated or not may be interesting,
that's said, you can already get the manifest file from the ModuleReader and check if there is an entry named Automatic-Module-Name so i'm not sure surfacing isNamed() in the API is a good idea.

> 
>     A user of a library can suggest a stable name to the library's
>     maintainer, and easily submit a patch that implements it.  This will
>     enable the uncoordinated modularization of libraries across the
>     entire ecosystem.
> 
> I don't think this is realistic. Jars live in the local repository and
> will stay there even during compilation. Is a user patches such jars,
> it'll effect all his local Java projects. Only when Maven will do both
> compiling and generation the distributable/deployable one could isolate
> jars. 

[...]

I think there is a misunderstanding here, 
i read 'easily submit a patch' as 'easily submit a pull request' that will change the source so the next time the jar is published on central, it will have a module name in its manifest.


> 
> thanks,
> Robert

Rémi

> 
> On Thu, 04 May 2017 19:39:06 +0200, <mark.reinhold at oracle.com> wrote:
> 
>> Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
>> Robert Scholte, for the extensive feedback.
>>
>>   http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html
>>
>> TL;DR: Keep automatic modules, bring back the module-name JAR-file
>> manifest attribute, and strongly recommend reverse-DNS module names.
>>
>> Comments?
>>
> > - Mark