One thing that is missing here is that you can only control the direct
dependencies, you cannot control the transitive dependencies.
To complete the example:
module com.mycompany:foo-utils {
requires guava; // automodule from google
}
but we also have
module com.acme:bar-utils {
requires guava; // automodule from acme
}
two modules which both require a guava module, though not the same guava
module.
With my application:
module myapplication {
requires com.mycompany:foo-utils;
requires com.acme:bar-utils;
}
I don't control foo-utils nor bar-utils, those are third party
dependencies.
This application requires 2 different guava modules, but without the
"groupId" you cannot decide which one to choose. The proposal to fail when
2 automodules have the same name implies that myapplication can never
become a module.
Maven has a project which cannot be transformed to a module with the
current and proposed specs:
Aether is a project which handles the artifact resolution of Maven. It was
first developed by Sonatype (groupId org.sonatype.aether; package
org.sonatype.aether.*), than handed over to Eclipse (groupId
org.eclipse.aether; package org.eclipse.aether.*). Maven 3.0.x uses
Sonatype's Aether, Maven 3.1+ uses Eclipse's Aether. (and we know there
won't be any Aether release by Sonatype nor by Eclipse)
For the Maven3 plugins which do something with artifact resolution and
transfer we wrote maven-artifact-transfer, which selects the proper group
of Aether artifacts based on the Maven version.
The current automodule naming is not strong enough to convert
maven-artifact-transfer to a module; it will simply not compile because of
the duplicate artifact names.
Robert
On Mon, 10 Oct 2016 13:47:45 +0200, Stephen Colebourne
<scolebou...@joda.org> wrote:
"At JavaOne I asked a question about the naming standards for modules
given that we have automatic modules.
The scenario is as follows:
- an open source module foo that depends on Google guava
- guava has not yet been modularised
- guava is provided by jar file guava-19.0.jar and used as an automatic
module
- foo declares "requires guava", where "guava" is a module name
derived from the jar file name
At some later time, guava is modularised, but chooses the sensible
module name "com.google.guava". Now, the module foo (released as open
source to maven central) has the wrong module name for guava.
Given this scenario, the Jigsaw team suggested that the correct module
name for guava is "guava". (The only alternative strategy at the
moment would be for open source projects published to maven central to
*never* declare requires on an automatic module).
I, and others, have expressed concern about a naming strategy for
modules that is not based on the reverse domain name strategy, eg
com.google or org.joda. It seems common to me that companies will have
modules that have the same name as publicly available modules in maven
central. The migration problem described above also seems overly
restrictive.
In addition, there are related problems to do with projects that fork
but want to retain the same name (maybe not desirable, but GutHub
forking is common).
Proposal
-------------
- a new concept *group name* should be introduced above module name
- the combination groupName:moduleName should always match the maven
group:artifact coordinates
- messaging in this way to the community will avoid migration issues
as the standard is already in use and accepted
- in module-info.java, the user must always specify both the group and
module name
- the requires clause may specify or omit the group name but always
has the module name
- best practice would be to include the group name to ensure reliable
configuration
- when depending on automatic modules, the group name would be omitted
- if omitted, the group name is inferred by the system from the
available modules on the module path
- automatic modules are in the unamed group
With this setup, the migration problem outlined above disappears. The
fully qualified name of guava would be "com.google.guava:guava", as
per maven naming standards [1]. Anybody who had depended on the
automatic module for guava using "requires guava" would still work (in
all except edge cases).
This would look for a module named "guava" in any group (likely to be
an automatic module). If found in two groups, the system fails to
start:
module com.mycompany:foo-utils {
requires guava;
}
This would look for a module named "guava" in group "com.google.guava:
module com.mycompany:foo-utils {
requires com.google.guava:guava;
}
This relates to #ModuleNameSyntax, in that the module name will be
more distinct - either with a colon, or being the short form. Ideally,
the convention would be for the module name to use dashes, not dots.
Thus, Joda-Beans would be "org.joda:joda-beans" when fully qualified.
Given the widespread adoption of maven, the combination of
group:artifact is very well known and accepted. It makes sense for
Java to adopt the convention.
(In fact, the way this is defined, it should be possible for Maven
Central / JCenter to run an automated job that adds a "weak module"
definition to all existing jars, using the maven coordinates as the
name. Whether this desirable to actually is debatable, but the fact
that it could be done strikes me as a good sign for migration.)
Stephen
[1]
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.google.guava%22%20AND%20a%3A%22guava%22
