Thats how I understand it as well and I like it. Brian Fox wrote on 2017-02-17 06:01:
> Hervé: I feel like I don't completely understand the proposal, but I feel > like we can achieve your intent using the Module-Name simply by defaulting > it to g:a and building up a good base of new stuff going into Central such > that when people start using jigsaw, there is a good pattern in place and > we've hopefully avoided conflicts. > > Am I mis-understanding your proposal? > > On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: > >> tuesday, I was at a Jigsaw presentation from Remi Forax in France, where >> the >> fact that nothing was taken into consideration looked something that was >> happenning (and the recent publication shows that it has happened now) >> >> Then Remi and I discussed and looked for ideas on what lighter proposal to >> do >> for the namespace concern when sharing modules publicly >> >> And I proposed a simplified idea that looked promising when we challenged >> it: >> for modules that are to be shared on Maven Central, >> handwritten full module name should *start with groupId* >> >> >> applied to the example for Hibernate, this would just say: Hibernate >> project >> owns "org.hibernate" module namespace on [Maven] Central since they own >> org.hibernate groupId >> >> Notice: automodules won't give same module names. Automodules are just >> transient automagic values for temporary local work, not for public shared >> work >> >> Notice 2: whatever does not go to [Maven] Central has just other >> conventions. >> Knowing the impact of existing [Maven] Central content, people doing their >> local convention will probably "naturally" think at: >> - immediate compatibility, to be able to consume public artifacts >> - future compatibility, to be able to later publish a private artifact that >> may be later shared as public artifact >> >> >> I started to share this idea (which is not far from initial proposal: just >> not >> about automodule names and not using artifactId) yesterday with Robert: >> the >> discussion just started, nobody had time yet to write the proposal down and >> share it with a wider audience >> >> >> WDYT? >> >> Regards, >> >> Hervé >> >> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit : >> > And it looks like they are saying .. just add the groupId (or similar >> > namespace) to the modulename. A bit like some artifact repeat the groupId >> > in the artifactId to be specific... seems like a wasted opportunity to >> > define a good usage pattern. The idea of actually supporting same module >> > names for different forks or the same thing is touted as an advantage. >> > Anybody that ever had to debug something like this will know its not an >> > advantage at all .. just simply path to troubleshooting nightmares. >> > >> > I expected as much but I am still disappointed and see lots of trouble >> with >> > this in the future. Maybe it would be good if all Apache project and >> others >> > that are going to publish modules start with using the full namespace in >> > the module name. Problem is of course that the examples I saw so far all >> do >> > NOT do that so we will end up with a mess anyway.. >> > >> > Manfred >> > >> > Brian Fox wrote on 2017-02-16 10:42: >> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com> >> wrote: >> > >> 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? >> > > >> > > Yes but this only applies to things that are modularized. The bigger >> issue >> > > is all the existing stuff that would be used as automodules...first >> they >> > > are already out there and second, there's nothing to see and block. >> > > >> > >> 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. >> > > >> > > That's exactly my point in originally suggesting to leverage the g:a by >> > > default, but we can do exactly the same thing by injecting the >> Module-Name >> > > asap to build up the right practices before jigsaw takes off. >> > > >> > >> -- >> > >> 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 >> > >> > --------------------------------------------------------------------- >> > 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
