Can't we just block auto-named modules from the build? We control dependencies and should be able to look inside and barf if we don't like anything, no?
I realize this does not set good defaults for non-maven projects, so there will be some friction there, but hopefully maven userbase is big enough to create sufficient pressure for non-maven projects to provide explicit module names. -- Regards, Igor On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote: > I generally agree the concerns were mostly ignored. Specifically the > dangers in not carefully approaching and setting best practices in the > names, thereby willfully ignoring what happened with NPM. > > The inclusion of the Module-Name metadata is frankly, more than I > expected > we would get. I think this does give us something to work with, first by > making that defaulted by the Maven plugins and later by enforcing in the > repo as appropriate. Using this correctly could help solve some of my > initial concerns that we weren't appropriately leveraging the > default-effect. > > PS: those of you who aren't sure what this was all about, see here: > http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/ > > On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser > <manf...@simpligility.com> > wrote: > > > I just read it all .. sigh. Looks like our concerns got ignored to me > > > > Manfred > > > > Robert Scholte wrote on 2017-02-16 09:23: > > > > > FYI, > > > > > > Robert > > > > > > ------- Forwarded message ------- > > > From: mark.reinh...@oracle.com > > > To: jpms-spec-expe...@openjdk.java.net > > > Cc: > > > Subject: How to name modules, automatic and otherwise > > > Date: Thu, 16 Feb 2017 17:48:27 +0100 > > > > > > This note is in reply to the concerns about automatic modules raised by > > > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others > > > [2]. I've collected my conclusions here rather than in separate messages > > > because there are several distinct yet intertwined issues. > > > > > > Summary: > > > > > > - Module names should not include Maven group identifiers, because > > > modules are more abstract than the artifacts that define them. > > > > > > - Module names should use the reverse-domain-name-prefix convention > > > or, preferably, the project-name-prefix convention. > > > > > > - We should not abandon automatic modules, since they are a key tool > > > for migration and adoption. > > > > > > - We can address the problems of automatic modules with two fairly > > > minor technical enhancements. > > > > > > If any of these points strikes you as controversial, please read on! > > > > > > * * * > > > > > > Module names should not include Maven group identifiers, as Robert > > > Scholte and Brian Fox suggest [1], even for modules declared explicitly > > > in `module-info.java` files. Modules in JPMS are a construct of the Java > > > programming language, implemented in both the compiler and the virtual > > > machine. As such, they are more abstract entities than the artifacts > > > that define them. This distinction is useful, both conceptually and > > > practically, hence module names should remain more abstract. > > > > > > This distinction is useful conceptually because it makes it easier, as > > > we read source code, to think clearly about the nature of a module. We > > > can reason about a module's dependences, exports, services, and so forth > > > without cluttering our minds with the details of group identifiers and > > > version constraints. Today, e.g., we can write, and read: > > > > > > module foo.data { > > > exports com.bar.foo.data; > > > requires hibernate.core; > > > requires hibernate.jcache; > > > requires hibernate.validator; > > > } > > > > > > If we were to extend the syntax of module names to include group > > > identifiers, and encourage people to use them, then we'd be faced with > > > something much more verbose: > > > > > > module com.bar:foo.data { > > > exports com.bar.foo.data; > > > requires org.hibernate:hibernate.core; > > > requires org.hibernate:hibernate.jcache; > > > requires org.hibernate:hibernate.validator; > > > } > > > > > > Group identifiers make perfect sense in the context of a build system > > > such as Maven, where they bring necessary structure to the names of the > > > millions of artifacts available across different repositories. Such > > > structure is superfluous and distracting in the context of a module > > > system, where the number of relevant modules in any particular situation > > > is more likely to be in the tens, or hundreds, or (rarely) thousands. > > > All else being equal, simpler names are better. > > > > > > At a practical level, the distinction between modules and artifacts is > > > useful because it leaves the entire problem of artifact selection to the > > > build system. This allows us to switch from one artifact to another > > > simply by editing a `pom.xml` file to adjust a version constraint or a > > > group identifier; if module names included group identifiers then we'd > > > also have to edit the `module-info.java` file. This flexibility can be > > > helpful if, e.g., a project is forked and a new module with the same name > > > and artifact identifier is published under a different group identifier. > > > We long ago decided not to do version selection in the module system, > > > which surprised some people but has worked out fairly well. We should > > > treat group selection in the same manner. > > > > > > Another practical benefit of the module/artifact distinction is that it > > > keeps the module system independent of any particular build system, so > > > that build systems can continue to improve and evolve independently over > > > time. Maven-style coordinates are the most popular way to name artifacts > > > in repositories today, but that might not be true ten years from now. It > > > would be unwise to adopt Maven's naming convention for module names just > > > because it's popular now, and doubly so to bake Maven's group-identifier > > > concept into the Java programming language. > > > > > > * * * > > > > > > If module names don't include group identifiers, then how should modules > > > be named? What advice should we give to someone who's creating a new > > > module from scratch, or modularizing an existing component by writing a > > > `module-info.java` file for it? (Continue to set aside, for the moment, > > > the problems of automatic modules.) > > > > > > In structuring any particular space of names we must balance (at least) > > > three fundamental tensions: We want names that are long enough to be > > > descriptive, short enough to be memorable, and unique enough to avoid > > > needless conflicts. > > > > > > If you control all of the modules upon which your module depends, and > > > all of the modules that depend upon it, then you can of course name your > > > module whatever you want, and change its name at any time. If, however, > > > you're going to publish your module for use by others -- whether just > > > within your own organization or to a global repository such as Maven > > > Central -- then you should take more care. There are two well-known > > > ways to go about this. > > > > > > - Choose module names that start with the reversed form of an Internet > > > domain name that you control, or are at least associated with. The > > > Java Language Specification has long suggested this convention as a > > > way to minimize conflicts amongst package names, and it has been > > > widely though not universally adopted for that purpose. > > > > > > - Choose module names that start with the name of your project or > > > product. Module (and package) names that start with reversed domain > > > names are less likely to conflict but they're unnecessarily verbose, > > > they start with the least-important information (e.g., `com`, `org`, > > > or `net`), and they don't read well after exogenous changes such as > > > open-source donations or corporate acquisitions (e.g., `com.sun.*`). > > > > > > The reversed domain-name approach was sensible in the early days of Java, > > > before we had development tools sophisticated enough to help us deal with > > > the occasional conflict. We have such tools now, so going forward the > > > superior readability of short module and package names that start with > > > project or product names is preferable to the onerous verbosity of those > > > that start with reversed domain names. > > > > > > This advice will strike some readers as controversial. I respect those > > > who will choose, for the sake of tradition or an abundance of caution, to > > > use the reversed domain-name convention for module names and continue to > > > use that convention for package names. I do know, however, of at least > > > one major, well-known project whose developers intend to adopt the > > > project-name-prefix convention for their module names. > > > > > > * * * > > > > > > If module names don't include group identifiers, then how should > > automatic > > > modules be named? Or are automatic modules so troublesome that we should > > > remove them from the design? > > > > > > To answer the second question first: It would be a tragic shame to drop > > > automatic modules, since otherwise top-down migration is impossible if > > > you're not willing to modify artifacts that you don't maintain, which > > > most people (quite sensibly) aren't. Even if you limit your use of > > > automatic modules to closed systems, as Stephen Colebourne suggests [2], > > > they're still of significant value. Let's see if we can rescue them. > > > > > > The present algorithm for naming automatic modules has two problems: > > > > > > (A) Conflicts are possible across large artifact repositories, since > > > the name of an automatic module is computed from the name of the > > > artifact that defines it. [1] > > > > > > (B) It's risky to publish a module that `requires` some other module > > > that has not yet been modularized, and hence must be used as an > > > automatic module. If the maintainer of that module later chooses > > > an explicit name different from the automatic name then you must > > > publish a new version of your module with an updated `requires` > > > directive. [2] > > > > > > As to (A), yes, conflicts exist, though it's worth observing that many of > > > the conflicts in the Maven Central data are due to poorly-chosen artifact > > > names: `parent`, `library`, `core`, and `common` top the list, which then > > > falls off in a long-tail distribution. When conflicts are detected then > > > build tools can rename artifacts either automatically or, preferably, to > > > user-specified names that map to sensible automatic-module names. If > > > renaming artifacts in the filesystem proves impractical then we could > > > extend the syntax of the `--module-path` option to allow a module name > > > to be specified for each specifically-named artifact, though strictly > > > speaking that would be a feature of the JDK rather than JPMS. > > > > > > We can address (B) by enabling the maintainers of existing components to > > > specify the module names that should be given to their components when > > > used as automatic modules, without having to write `module-info.java` > > > files. This can be done very simply, with a single new JAR-file manifest > > > `Module-Name` attribute, as first suggested almost a year ago [3]. > > > > > > If we add this one feature then the maintainer of an existing component > > > that, e.g., must still build and run on JDK 7 can choose a module name > > > for that component, record it in the manifest by adding a few lines to > > > the `pom.xml` file, and tell users that they can use it as an automatic > > > module on JDK 9 without fear that the module name will change when the > > > component is properly modularized some years from now. The actual change > > > to the component is small and low-risk, so it can reasonably be done in > > > a patch release. There's no need to write a `module-info.java` file, > > > and in fact doing so may be inadvisable at this point if the component > > > depends on other components that have not yet been given module names. > > > > > > This approach for (B) does add one more (optional) step to the migration > > > path, but it will hopefully lead to a larger number of explicitly-named > > > modules in the world -- and in particular in Maven Central -- sooner > > > rather than later. > > > > > > - Mark > > > > > > > > > [1] > > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > > 2017-January/000537.html > > > [2] > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- > > January/011106.html > > > [3] > > > http://openjdk.java.net/projects/jigsaw/spec/issues/# > > ModuleNameInManifest > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
