> > The idea is to not default to group:artifact but to check if the artifact > starts with a suffix of the group-ID and then skip this. So g=org.hibernate > a=hibernate-core would become org.hibernate.core and not > org.hibernate.hibernate.core. This is a neat trick I wished in the past in > some repository listings as well. However there is room for conflicts: > org.hibernate:hibernate-util and org.hibernate:util would fold to the same > module :-( (However it is most likely better to default to the shorter > version and ask people to specify a longer version in case of conflicts)?
2017-02-17 15:01 GMT+01:00 Brian Fox <bri...@infinity.nu>: > 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 > > > > >
