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".
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. However, the concept is that plugins don't have any knowledge of
each other and shouldn't share any information. In other words:
maven-war-plugin is not aware of maven-compiler-plugin; the
maven-war-plugin just collects all the content for the web archive,
including the jars as specified in the pom.xml, pulling them from the
local repository.
In case the user is developing an application he might use this, but since
he can already use automodules, I expect him to use that, it's less
painful compared to patching its dependencies artifacts.
In case the user is developing a library he cannot use this, nor can he
refer to automodule, because he doesn't control the combinations of jars
used by the application developer.
thanks,
Robert
On Thu, 04 May 2017 19:39:06 +0200, <mark.reinh...@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
