Re: Fwd: How to name modules, automatic and otherwise

[Stephen Connolly]

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

[Hervé BOUTEMY]

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

[Christian Schulte]

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

[Robert Scholte]

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;
> 

Re: Fwd: How to name modules, automatic and otherwise

[Hervé BOUTEMY]

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

[Christian Schulte]

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

[Hervé BOUTEMY]

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 

Re: Fwd: How to name modules, automatic and otherwise

[Robert Scholte]

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 

Re: Fwd: How to name modules, automatic and otherwise

[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.


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 

Re: Fwd: How to name modules, automatic and otherwise

[Hervé BOUTEMY]

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

Re: Fwd: How to name modules, automatic and otherwise

[Bernd]

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

Re: Fwd: How to name modules, automatic and otherwise

[Manfred Moser]

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 

Re: Fwd: How to name modules, automatic and otherwise

[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
> > >>
> > >> 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 

Re: Fwd: How to name modules, automatic and otherwise

[Hervé BOUTEMY]

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 

Re: Fwd: How to name modules, automatic and otherwise

[Manfred Moser]

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 

Re: Fwd: How to name modules, automatic and otherwise

[Brian Fox]

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;
> > > >  

Re: Fwd: How to name modules, automatic and otherwise

[Igor Fedorenko]

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

Re: Fwd: How to name modules, automatic and otherwise

[Brian Fox]

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 

Re: Fwd: How to name modules, automatic and otherwise

[Manfred Moser]

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 

Fwd: How to name modules, automatic and otherwise

[Robert Scholte]

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