Re: Fwd: How to name modules, automatic and otherwise
Yep. We can be opinionated, but we should allow others to follow their own opinions (even if they are "wrong")... we just don't have to make it easy! On Tue 21 Feb 2017 at 22:16, Hervé BOUTEMY wrote: > Maven tool can't check everything against developper's will: we already > have > bad reputation because we put contraints on the build. > > We can't force people, we can't enforce rules. > > We can define good conventions and ease their use. > > Regards, > > Hervé > > Le mardi 21 février 2017, 03:41:12 CET Christian Schulte a écrit : > > Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY: > > > then I'm not sure checking rules on what is inside an artifact while > > > publishing in Central is the right thing to do: we don't do it > currently > > > (checking that package names are consistent with groupId), then I feel > we > > > should not do it either for module info > > > > If we would have checked that, there would not be this "redundant class > > files on class path coming from different coordinates" issue. > > > > > it's just a basic convention for normal cases, that will be applied > more > > > than 90% of time: and there will be less than 10% of time where > > > discrepency will happen, due to some special cases in code life > > > As usual > > > > Issue with the module names is the same as with the package or > > classnames. They can be deployed to different coordinates and then > > produce conflicts later when consumed. If we can avoid this with module > > names, we should. > > > > Regards, > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Fwd: How to name modules, automatic and otherwise
Maven tool can't check everything against developper's will: we already have bad reputation because we put contraints on the build. We can't force people, we can't enforce rules. We can define good conventions and ease their use. Regards, Hervé Le mardi 21 février 2017, 03:41:12 CET Christian Schulte a écrit : > Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY: > > then I'm not sure checking rules on what is inside an artifact while > > publishing in Central is the right thing to do: we don't do it currently > > (checking that package names are consistent with groupId), then I feel we > > should not do it either for module info > > If we would have checked that, there would not be this "redundant class > files on class path coming from different coordinates" issue. > > > it's just a basic convention for normal cases, that will be applied more > > than 90% of time: and there will be less than 10% of time where > > discrepency will happen, due to some special cases in code life > > As usual > > Issue with the module names is the same as with the package or > classnames. They can be deployed to different coordinates and then > produce conflicts later when consumed. If we can avoid this with module > names, we should. > > Regards, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: How to name modules, automatic and otherwise
Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY: > then I'm not sure checking rules on what is inside an artifact while > publishing in Central is the right thing to do: we don't do it currently > (checking that package names are consistent with groupId), then I feel we > should not do it either for module info If we would have checked that, there would not be this "redundant class files on class path coming from different coordinates" issue. > > it's just a basic convention for normal cases, that will be applied more than > 90% of time: and there will be less than 10% of time where discrepency will > happen, due to some special cases in code life > As usual Issue with the module names is the same as with the package or classnames. They can be deployed to different coordinates and then produce conflicts later when consumed. If we can avoid this with module names, we should. Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: How to name modules, automatic and otherwise
On Sat, 18 Feb 2017 12:46:32 +0100, Robert Scholte wrote: On Thu, 16 Feb 2017 19:11:33 +0100, 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. It doesn't take away the issue that you can still refer to automodules and that their name can/will change in the future. I think we should introduce 2 new packaging types: - modlib, which does not allow references to automodules - modapp, which allows references to automodules, but will never be installed or deployed. After some rethinking we can solve this all with the current jar packaging type. If module-info doesn't export any packages it is considered an application and we can allow automodules. If there are exports defined, it is considered a dependency meaning we cannot allow automodules, but only named modules. Robert In fact, modapp matches one of my ideas for POM5 where GA are not always required anymore, e.g. if they are not distributed as dependency. 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. Hmm, not sure about the default behavior. I think developers should choose their name with care, just as they should choose their groupId and artifactId with care. The Module-Name will make it possible to prepare your project as modular jar. This also implies that in the module-info you must specify *every* requirement. If only one jar is not yet a named module (either by Module-Name or by module-info), you must omit the module-info.java; that's a choice, makes our lives a bit easier :) Just have to be very clear about it towards the community. Robert 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 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; > require
Re: Fwd: How to name modules, automatic and otherwise
IMHO, this means that there is the vast majority of "normal" case then there is life, where exceptionnally everything is mixed: - publishing a temporary fork (for example to have some local patches) - really forking or moving then I'm not sure checking rules on what is inside an artifact while publishing in Central is the right thing to do: we don't do it currently (checking that package names are consistent with groupId), then I feel we should not do it either for module info it's just a basic convention for normal cases, that will be applied more than 90% of time: and there will be less than 10% of time where discrepency will happen, due to some special cases in code life As usual Regards, Hervé Le dimanche 19 février 2017, 00:45:29 CET Christian Schulte a écrit : > Am 02/18/17 um 12:25 schrieb Robert Scholte: > > The idea from Hervé and Rémi is about having a publish rule in Central if > > you want to publish a modular jar there which will prevent module name > > collisions. > > Because the groupId is already owned by a specific organisation, you could > > use them as well as "namespace"/prefix of the modular name to ensure that > > within Central modular names are unique. > > > > However, this collides with the idea from Mark who says that it should be > > possible to move a modulename from one organisation to another. That > > should only effect the GA, not the module name. > > Like we did with the resolver. Changed the coordinates but did not > change package names and class names. So the module name should not > change as well. This means the coordinates are nothing to consider for > the module names but package names and class names (the content - not > the coordinates). > > Regards, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: How to name modules, automatic and otherwise
Am 02/18/17 um 12:25 schrieb Robert Scholte: > The idea from Hervé and Rémi is about having a publish rule in Central if > you want to publish a modular jar there which will prevent module name > collisions. > Because the groupId is already owned by a specific organisation, you could > use them as well as "namespace"/prefix of the modular name to ensure that > within Central modular names are unique. > > However, this collides with the idea from Mark who says that it should be > possible to move a modulename from one organisation to another. That > should only effect the GA, not the module name. Like we did with the resolver. Changed the coordinates but did not change package names and class names. So the module name should not change as well. This means the coordinates are nothing to consider for the module names but package names and class names (the content - not the coordinates). Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fwd: How to name modules, automatic and otherwise
yes, that's it (eventually without even checking that rule automatically when publishing into central: just making an explicit convention to avoid stupid choice of module prefix that is different from groupId but another DNS entry one may own) Regards, Hervé Le samedi 18 février 2017, 12:25:40 CET Robert Scholte a écrit : > The idea from Hervé and Rémi is about having a publish rule in Central if > you want to publish a modular jar there which will prevent module name > collisions. > Because the groupId is already owned by a specific organisation, you could > use them as well as "namespace"/prefix of the modular name to ensure that > within Central modular names are unique. > > However, this collides with the idea from Mark who says that it should be > possible to move a modulename from one organisation to another. That > should only effect the GA, not the module name. > > So to be clear, Hervé and Rémi are *not* talking about automodules and how > they should get their name, but only about named modules. > > Robert > > On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox wrote: > > 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 > > > > 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 > >> > >> > >> > >> 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 > >> >
Re: Fwd: How to name modules, automatic and otherwise
On Thu, 16 Feb 2017 19:11:33 +0100, 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. It doesn't take away the issue that you can still refer to automodules and that their name can/will change in the future. I think we should introduce 2 new packaging types: - modlib, which does not allow references to automodules - modapp, which allows references to automodules, but will never be installed or deployed. In fact, modapp matches one of my ideas for POM5 where GA are not always required anymore, e.g. if they are not distributed as dependency. 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. Hmm, not sure about the default behavior. I think developers should choose their name with care, just as they should choose their groupId and artifactId with care. The Module-Name will make it possible to prepare your project as modular jar. This also implies that in the module-info you must specify *every* requirement. If only one jar is not yet a named module (either by Module-Name or by module-info), you must omit the module-info.java; that's a choice, makes our lives a bit easier :) Just have to be very clear about it towards the community. Robert 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 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
Re: Fwd: How to name modules, automatic and otherwise
The idea from Hervé and Rémi is about having a publish rule in Central if you want to publish a modular jar there which will prevent module name collisions. Because the groupId is already owned by a specific organisation, you could use them as well as "namespace"/prefix of the modular name to ensure that within Central modular names are unique. However, this collides with the idea from Mark who says that it should be possible to move a modulename from one organisation to another. That should only effect the GA, not the module name. So to be clear, Hervé and Rémi are *not* talking about automodules and how they should get their name, but only about named modules. Robert On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox wrote: 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 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 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
Re: Fwd: How to name modules, automatic and otherwise
there is some level of misunderstanding my proposal is not to force any default value: just check (for people publishing to Central) that chosen value starts with groupId then, in some Maven plugin, we can independently propose magic help to propose auto-calculated default values to people using Maven, that will be injected in Module-Name: since this Maven plugin will respect the previous Central convention (value starts with groupId), this will be ok. I'm not sure that proposing automagic values for target module names (ie not automodule names derived from file name) is safe: when a developper wants to really take Java 9 module names in consideration (either by migrating to a real module, either by defining a Module-Name property in his manifest), he really has to know that he's committed to this name. If the white magic algorithm to propose a name does not find a name that has human sense (for whatever reason), that will be problematic. Notice that the fact that you seem to propose an algorigthm where the generated name has a colon in it surprised me: are colons accepted in a Jigsaw module name? Notice 2: I like the proposal of Module-Name MANIFEST.MF property to let a developper influence the name of his automodule, without migrating to Jigsaw yet: very nice idea Regards, Hervé Le vendredi 17 février 2017, 09:01:46 CET Brian Fox a écrit : > 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 > > 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 > > > > 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
Re: Fwd: How to name modules, automatic and otherwise
> > 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 : > 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 > 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 > > > 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
Re: Fwd: How to name modules, automatic and otherwise
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 > 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 >> 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
Re: Fwd: How to name modules, automatic and otherwise
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 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 > 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.sonat
Re: Fwd: How to name modules, automatic and otherwise
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 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 > >> > > >> > > >> > 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 > >> > > >
Re: Fwd: How to name modules, automatic and otherwise
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 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 >> > >> > 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 ma
Re: Fwd: How to name modules, automatic and otherwise
On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko 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 > > > > 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; > > > >
Re: Fwd: How to name modules, automatic and otherwise
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 > > 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
Re: Fwd: How to name modules, automatic and otherwise
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 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 modul
Re: Fwd: How to name modules, automatic and otherwise
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 partic
Fwd: How to name modules, automatic and otherwise
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