Module names - related to #ModuleNameSyntax

[Robert Scholte]

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  
<scolebourne at 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