Re: Releasing Maven Resolver 1.1.0

2017-05-31 Thread Hervé BOUTEMY
I removed the test-util module: yes, not expected to be a runtime dependency.
And this offers the opportunity to put the jar plugin configuration in a 
"java9-module" profile

but I kept module name in javadoc group: we're not building with JDK 9 (and it 
currently does not work, requires some tuning), need a solution waiting for 
real Java 9 modules with JDK 9 javadoc output

Regards,

Hervé

Le mardi 30 mai 2017, 20:16:59 CEST Robert Scholte a écrit :
> I'm having my doubts if we should add the module name in the title of
> Javadoc.
> 
> Have a look at the Java 9 javadoc, which has a lot of module info "out of
> the box".
> 
> Robert
> 
> On Tue, 30 May 2017 07:58:54 +0200, Robert Scholte 
> 
> wrote:
> > How about ignoring the testutil? It should never become a runtime
> > dependency, so I don't expect any project will refer to it, hence why
> > give it a module name?
> > 
> > Robert
> > 
> > On Tue, 30 May 2017 01:26:52 +0200, Hervé BOUTEMY
> > 
> >  wrote:
> >> commit proposed in a new branch
> >> and generated site from this branch published for review:
> >> - aggregated javadoc
> >> https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.
> >> html
> >> 
> >> - API javadoc
> >> https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver
> >> -api/ apidocs/index.html
> >> 
> >> - Implementation javadoc
> >> http://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-> 
> >> >> impl/ apidocs/index.html
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le mardi 30 mai 2017, 01:05:24 CEST Hervé BOUTEMY a écrit :
> >>> another complementary reaction while reviewing consistency between java
> >>> package names and modules names: perhaps we should change
> >>> org.apache.maven.resolver.testutil
> >>> to org.apache.maven.resolver.internal.test.util
> >>> 
> >>> Regards,
> >>> 
> >>> Hervé
> >>> 
> >>> Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit :
> >>> > one associated question I had in mind: how do we document to end
> >>> 
> >>> users
> >>> 
> >>> > what
> >>> > are the module names? Should we add a report to MPIR? And how could
> >>> 
> >>> this
> >>> 
> >>> > report work, particularly on Automatic Module Name?
> >>> > 
> >>> > I'm torn on choosing module name for this component: I think I
> >>> 
> >>> understand
> >>> 
> >>> > Stephen's logic.
> >>> > Whatever name we choose, there will be a hard step when we move out
> >>> 
> >>> of
> >>> 
> >>> > org.eclipse.aether package in Maven Resolver 2.0.
> >>> > 
> >>> > I'm not sure choosing org.eclipse.aether.* module names for Maven
> >>> 
> >>> Resolver
> >>> 
> >>> > 1.x and org.apache.maven.resolver.* module names for Maven Resolver
> >>> 
> >>> 2.x
> >>> 
> >>> > will ease the transition: whatever the choice, the tricky history of
> >>> 
> >>> this
> >>> 
> >>> > component will make its references tricky.
> >>> > 
> >>> > While we do the trick at Maven artifact coords level, being
> >>> 
> >>> consistent on
> >>> 
> >>> > the same trick at module names.
> >>> > One idea: perhaps adding the module names in consolidated javadoc
> >>> 
> >>> groups
> >>> 
> >>> > [1] may be a solution to document the hard choice.
> >>> > 
> >>> > Regards,
> >>> > 
> >>> > Hervé
> >>> > 
> >>> > [1]
> >>> 
> >>> http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/
> >>> 
> >>> > index.html
> >>> > 
> >>> > Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> >>> > > Well, you have my opinion. I don't think there is an exemption here
> >>> > > just because the component has a tricky history, and I personally
> >>> > > think that any exemption for the package name necessarily applies
> >>> 
> >>> to
> >>> 
> >>> > > the module name (since it is now generally agreed that the module
> >>> 
> >>> name
> >>> 
> >>> > > derives from the package name).
> >>> > > 
> >>> > > Doing otherwise will end up being confusing as more and more people
> >>> > > name modules after super-packages.
> >>> > > 
> >>> > > Stephen
> >>> > > 
> >>> > > On 29 May 2017 at 18:46, Robert Scholte 
> >>> 
> >>> wrote:
> >>> > > > This makes it an interesting case :)
> >>> > > > 
> >>> > > > In short: the name "Aether" is owned by Eclipse and we are not
> >>> 
> >>> allowed
> >>> 
> >>> > > > to
> >>> > > > use it.
> >>> > > > However, we are allowed to use these packages for compatibility
> >>> > > > reasons
> >>> > > > as
> >>> > > > long as needed.
> >>> > > > 
> >>> > > > Module names are not part of this compatibility requirement, so
> >>> 
> >>> we
> >>> 
> >>> > > > shouldn't use the name Aether here.
> >>> > > > Will there be an org.apache.maven.resolver package-based
> >>> > > > implementation?
> >>> > > > Not sure, but could very well be.
> >>> > > > 
> >>> > > > Based on that I think we're now using the correct/preferred
> >>> 
> >>> module
> >>> 
> >>> > > > names.
> >>> > > > 
> >>> > > > thanks,
> >>> > > > Robert
> >>> > > > 
> >>> > > > 
> >>> > > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> >>> 

Re: Releasing Maven Resolver 1.1.0

2017-05-30 Thread Robert Scholte
I'm having my doubts if we should add the module name in the title of  
Javadoc.


Have a look at the Java 9 javadoc, which has a lot of module info "out of  
the box".


Robert

On Tue, 30 May 2017 07:58:54 +0200, Robert Scholte   
wrote:


How about ignoring the testutil? It should never become a runtime  
dependency, so I don't expect any project will refer to it, hence why  
give it a module name?


Robert

On Tue, 30 May 2017 01:26:52 +0200, Hervé BOUTEMY  
 wrote:



commit proposed in a new branch
and generated site from this branch published for review:
- aggregated javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html

- API javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-api/
apidocs/index.html

- Implementation javadoc
http://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-impl/
apidocs/index.html

Regards,

Hervé

Le mardi 30 mai 2017, 01:05:24 CEST Hervé BOUTEMY a écrit :

another complementary reaction while reviewing consistency between java
package names and modules names: perhaps we should change
org.apache.maven.resolver.testutil
to org.apache.maven.resolver.internal.test.util

Regards,

Hervé

Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit :
> one associated question I had in mind: how do we document to end  
users

> what
> are the module names? Should we add a report to MPIR? And how could  
this

> report work, particularly on Automatic Module Name?
>
> I'm torn on choosing module name for this component: I think I  
understand

> Stephen's logic.
> Whatever name we choose, there will be a hard step when we move out  
of

> org.eclipse.aether package in Maven Resolver 2.0.
>
> I'm not sure choosing org.eclipse.aether.* module names for Maven  
Resolver
> 1.x and org.apache.maven.resolver.* module names for Maven Resolver  
2.x
> will ease the transition: whatever the choice, the tricky history of  
this

> component will make its references tricky.
>
> While we do the trick at Maven artifact coords level, being  
consistent on

> the same trick at module names.
> One idea: perhaps adding the module names in consolidated javadoc  
groups

> [1] may be a solution to document the hard choice.
>
> Regards,
>
> Hervé
>
> [1]  
http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/

> index.html
>
> Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> > Well, you have my opinion. I don't think there is an exemption here
> > just because the component has a tricky history, and I personally
> > think that any exemption for the package name necessarily applies  
to
> > the module name (since it is now generally agreed that the module  
name

> > derives from the package name).
> >
> > Doing otherwise will end up being confusing as more and more people
> > name modules after super-packages.
> >
> > Stephen
> >
> > On 29 May 2017 at 18:46, Robert Scholte   
wrote:

> > > This makes it an interesting case :)
> > >
> > > In short: the name "Aether" is owned by Eclipse and we are not  
allowed

> > > to
> > > use it.
> > > However, we are allowed to use these packages for compatibility
> > > reasons
> > > as
> > > long as needed.
> > >
> > > Module names are not part of this compatibility requirement, so  
we

> > > shouldn't use the name Aether here.
> > > Will there be an org.apache.maven.resolver package-based
> > > implementation?
> > > Not sure, but could very well be.
> > >
> > > Based on that I think we're now using the correct/preferred  
module

> > > names.
> > >
> > > thanks,
> > > Robert
> > >
> > >
> > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> > >
> > >  wrote:
> > >> The module name should in almost all cases be the super-package  
of

> > >> the
> > >> project.
> > >> Don't use underscores in the module name unless they are also  
used in

> > >> the package name.
> > >>
> > >> If the super-package is "org.apache.maven.resolver.api" then  
that is

> > >> what the module name should be.
> > >> But if the super-package is "org.apache.maven.resolver" then  
that is

> > >> what the module name should be.
> > >>
> > >> ie. don't add ".api" just because that is what the artifact is
> > >> called.
> > >> Artifact name != module name.
> > >>
> > >> However, when I look at the source tree, it seems that the
> > >> super-package name is "org.eclipse.aether". If I'm right, then  
that

> > >> should be the module name. And maven-resolver-impl is a problem
> > >> because it has two super-packages, but the module name should
> > >> probably
> > >> be "org.eclipse.aether.impl" with the internal package moved  
under

> > >> impl.
> > >>
> > >> In summary, ignore the artifact name! Its the package name that
> > >> matters when defining the module name.
> > >>
> > >> Stephen
> > >>
> > >> On 27 May 2017 at 17:43, Robert Scholte   
wrote:

> > >>> There's no experience with this yet.
> > >>>
> > >>> Stephen Colebourne has written to related blogs: module  
naming

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Robert Scholte
How about ignoring the testutil? It should never become a runtime  
dependency, so I don't expect any project will refer to it, hence why give  
it a module name?


Robert

On Tue, 30 May 2017 01:26:52 +0200, Hervé BOUTEMY   
wrote:



commit proposed in a new branch
and generated site from this branch published for review:
- aggregated javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html

- API javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-api/
apidocs/index.html

- Implementation javadoc
http://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-impl/
apidocs/index.html

Regards,

Hervé

Le mardi 30 mai 2017, 01:05:24 CEST Hervé BOUTEMY a écrit :

another complementary reaction while reviewing consistency between java
package names and modules names: perhaps we should change
org.apache.maven.resolver.testutil
to org.apache.maven.resolver.internal.test.util

Regards,

Hervé

Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit :
> one associated question I had in mind: how do we document to end users
> what
> are the module names? Should we add a report to MPIR? And how could  
this

> report work, particularly on Automatic Module Name?
>
> I'm torn on choosing module name for this component: I think I  
understand

> Stephen's logic.
> Whatever name we choose, there will be a hard step when we move out of
> org.eclipse.aether package in Maven Resolver 2.0.
>
> I'm not sure choosing org.eclipse.aether.* module names for Maven  
Resolver
> 1.x and org.apache.maven.resolver.* module names for Maven Resolver  
2.x
> will ease the transition: whatever the choice, the tricky history of  
this

> component will make its references tricky.
>
> While we do the trick at Maven artifact coords level, being  
consistent on

> the same trick at module names.
> One idea: perhaps adding the module names in consolidated javadoc  
groups

> [1] may be a solution to document the hard choice.
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/
> index.html
>
> Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> > Well, you have my opinion. I don't think there is an exemption here
> > just because the component has a tricky history, and I personally
> > think that any exemption for the package name necessarily applies to
> > the module name (since it is now generally agreed that the module  
name

> > derives from the package name).
> >
> > Doing otherwise will end up being confusing as more and more people
> > name modules after super-packages.
> >
> > Stephen
> >
> > On 29 May 2017 at 18:46, Robert Scholte   
wrote:

> > > This makes it an interesting case :)
> > >
> > > In short: the name "Aether" is owned by Eclipse and we are not  
allowed

> > > to
> > > use it.
> > > However, we are allowed to use these packages for compatibility
> > > reasons
> > > as
> > > long as needed.
> > >
> > > Module names are not part of this compatibility requirement, so we
> > > shouldn't use the name Aether here.
> > > Will there be an org.apache.maven.resolver package-based
> > > implementation?
> > > Not sure, but could very well be.
> > >
> > > Based on that I think we're now using the correct/preferred module
> > > names.
> > >
> > > thanks,
> > > Robert
> > >
> > >
> > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> > >
> > >  wrote:
> > >> The module name should in almost all cases be the super-package  
of

> > >> the
> > >> project.
> > >> Don't use underscores in the module name unless they are also  
used in

> > >> the package name.
> > >>
> > >> If the super-package is "org.apache.maven.resolver.api" then  
that is

> > >> what the module name should be.
> > >> But if the super-package is "org.apache.maven.resolver" then  
that is

> > >> what the module name should be.
> > >>
> > >> ie. don't add ".api" just because that is what the artifact is
> > >> called.
> > >> Artifact name != module name.
> > >>
> > >> However, when I look at the source tree, it seems that the
> > >> super-package name is "org.eclipse.aether". If I'm right, then  
that

> > >> should be the module name. And maven-resolver-impl is a problem
> > >> because it has two super-packages, but the module name should
> > >> probably
> > >> be "org.eclipse.aether.impl" with the internal package moved  
under

> > >> impl.
> > >>
> > >> In summary, ignore the artifact name! Its the package name that
> > >> matters when defining the module name.
> > >>
> > >> Stephen
> > >>
> > >> On 27 May 2017 at 17:43, Robert Scholte   
wrote:

> > >>> There's no experience with this yet.
> > >>>
> > >>> Stephen Colebourne has written to related blogs: module  
naming[1]

> > >>> and
> > >>> modules are not artifacts[2]
> > >>> which might suggest that "api" should not be added.
> > >>> I do understand the addition of "api". And to make it worse,  
this is
> > >>> probably the most important artifact needing a module name

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
commit proposed in a new branch
and generated site from this branch published for review:
- aggregated javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html

- API javadoc
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-api/
apidocs/index.html

- Implementation javadoc
http://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-impl/
apidocs/index.html

Regards,

Hervé

Le mardi 30 mai 2017, 01:05:24 CEST Hervé BOUTEMY a écrit :
> another complementary reaction while reviewing consistency between java
> package names and modules names: perhaps we should change
> org.apache.maven.resolver.testutil
> to org.apache.maven.resolver.internal.test.util
> 
> Regards,
> 
> Hervé
> 
> Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit :
> > one associated question I had in mind: how do we document to end users
> > what
> > are the module names? Should we add a report to MPIR? And how could this
> > report work, particularly on Automatic Module Name?
> > 
> > I'm torn on choosing module name for this component: I think I understand
> > Stephen's logic.
> > Whatever name we choose, there will be a hard step when we move out of
> > org.eclipse.aether package in Maven Resolver 2.0.
> > 
> > I'm not sure choosing org.eclipse.aether.* module names for Maven Resolver
> > 1.x and org.apache.maven.resolver.* module names for Maven Resolver 2.x
> > will ease the transition: whatever the choice, the tricky history of this
> > component will make its references tricky.
> > 
> > While we do the trick at Maven artifact coords level, being consistent on
> > the same trick at module names.
> > One idea: perhaps adding the module names in consolidated javadoc groups
> > [1] may be a solution to document the hard choice.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/
> > index.html
> > 
> > Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> > > Well, you have my opinion. I don't think there is an exemption here
> > > just because the component has a tricky history, and I personally
> > > think that any exemption for the package name necessarily applies to
> > > the module name (since it is now generally agreed that the module name
> > > derives from the package name).
> > > 
> > > Doing otherwise will end up being confusing as more and more people
> > > name modules after super-packages.
> > > 
> > > Stephen
> > > 
> > > On 29 May 2017 at 18:46, Robert Scholte  wrote:
> > > > This makes it an interesting case :)
> > > > 
> > > > In short: the name "Aether" is owned by Eclipse and we are not allowed
> > > > to
> > > > use it.
> > > > However, we are allowed to use these packages for compatibility
> > > > reasons
> > > > as
> > > > long as needed.
> > > > 
> > > > Module names are not part of this compatibility requirement, so we
> > > > shouldn't use the name Aether here.
> > > > Will there be an org.apache.maven.resolver package-based
> > > > implementation?
> > > > Not sure, but could very well be.
> > > > 
> > > > Based on that I think we're now using the correct/preferred module
> > > > names.
> > > > 
> > > > thanks,
> > > > Robert
> > > > 
> > > > 
> > > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> > > > 
> > > >  wrote:
> > > >> The module name should in almost all cases be the super-package of
> > > >> the
> > > >> project.
> > > >> Don't use underscores in the module name unless they are also used in
> > > >> the package name.
> > > >> 
> > > >> If the super-package is "org.apache.maven.resolver.api" then that is
> > > >> what the module name should be.
> > > >> But if the super-package is "org.apache.maven.resolver" then that is
> > > >> what the module name should be.
> > > >> 
> > > >> ie. don't add ".api" just because that is what the artifact is
> > > >> called.
> > > >> Artifact name != module name.
> > > >> 
> > > >> However, when I look at the source tree, it seems that the
> > > >> super-package name is "org.eclipse.aether". If I'm right, then that
> > > >> should be the module name. And maven-resolver-impl is a problem
> > > >> because it has two super-packages, but the module name should
> > > >> probably
> > > >> be "org.eclipse.aether.impl" with the internal package moved under
> > > >> impl.
> > > >> 
> > > >> In summary, ignore the artifact name! Its the package name that
> > > >> matters when defining the module name.
> > > >> 
> > > >> Stephen
> > > >> 
> > > >> On 27 May 2017 at 17:43, Robert Scholte  wrote:
> > > >>> There's no experience with this yet.
> > > >>> 
> > > >>> Stephen Colebourne has written to related blogs: module naming[1]
> > > >>> and
> > > >>> modules are not artifacts[2]
> > > >>> which might suggest that "api" should not be added.
> > > >>> I do understand the addition of "api". And to make it worse, this is
> > > >>> probably the most important artifact needing a module name. In most
> > > >>> cases
> > > >>> devel

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
another complementary reaction while reviewing consistency between java 
package names and modules names: perhaps we should change
org.apache.maven.resolver.testutil
to org.apache.maven.resolver.internal.test.util

Regards,

Hervé

Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit :
> one associated question I had in mind: how do we document to end users what
> are the module names? Should we add a report to MPIR? And how could this
> report work, particularly on Automatic Module Name?
> 
> I'm torn on choosing module name for this component: I think I understand
> Stephen's logic.
> Whatever name we choose, there will be a hard step when we move out of
> org.eclipse.aether package in Maven Resolver 2.0.
> 
> I'm not sure choosing org.eclipse.aether.* module names for Maven Resolver
> 1.x and org.apache.maven.resolver.* module names for Maven Resolver 2.x
> will ease the transition: whatever the choice, the tricky history of this
> component will make its references tricky.
> 
> While we do the trick at Maven artifact coords level, being consistent on
> the same trick at module names.
> One idea: perhaps adding the module names in consolidated javadoc groups [1]
> may be a solution to document the hard choice.
> 
> Regards,
> 
> Hervé
> 
> [1] http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/
> index.html
> 
> Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> > Well, you have my opinion. I don't think there is an exemption here
> > just because the component has a tricky history, and I personally
> > think that any exemption for the package name necessarily applies to
> > the module name (since it is now generally agreed that the module name
> > derives from the package name).
> > 
> > Doing otherwise will end up being confusing as more and more people
> > name modules after super-packages.
> > 
> > Stephen
> > 
> > On 29 May 2017 at 18:46, Robert Scholte  wrote:
> > > This makes it an interesting case :)
> > > 
> > > In short: the name "Aether" is owned by Eclipse and we are not allowed
> > > to
> > > use it.
> > > However, we are allowed to use these packages for compatibility reasons
> > > as
> > > long as needed.
> > > 
> > > Module names are not part of this compatibility requirement, so we
> > > shouldn't use the name Aether here.
> > > Will there be an org.apache.maven.resolver package-based implementation?
> > > Not sure, but could very well be.
> > > 
> > > Based on that I think we're now using the correct/preferred module
> > > names.
> > > 
> > > thanks,
> > > Robert
> > > 
> > > 
> > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> > > 
> > >  wrote:
> > >> The module name should in almost all cases be the super-package of the
> > >> project.
> > >> Don't use underscores in the module name unless they are also used in
> > >> the package name.
> > >> 
> > >> If the super-package is "org.apache.maven.resolver.api" then that is
> > >> what the module name should be.
> > >> But if the super-package is "org.apache.maven.resolver" then that is
> > >> what the module name should be.
> > >> 
> > >> ie. don't add ".api" just because that is what the artifact is called.
> > >> Artifact name != module name.
> > >> 
> > >> However, when I look at the source tree, it seems that the
> > >> super-package name is "org.eclipse.aether". If I'm right, then that
> > >> should be the module name. And maven-resolver-impl is a problem
> > >> because it has two super-packages, but the module name should probably
> > >> be "org.eclipse.aether.impl" with the internal package moved under
> > >> impl.
> > >> 
> > >> In summary, ignore the artifact name! Its the package name that
> > >> matters when defining the module name.
> > >> 
> > >> Stephen
> > >> 
> > >> On 27 May 2017 at 17:43, Robert Scholte  wrote:
> > >>> There's no experience with this yet.
> > >>> 
> > >>> Stephen Colebourne has written to related blogs: module naming[1] and
> > >>> modules are not artifacts[2]
> > >>> which might suggest that "api" should not be added.
> > >>> I do understand the addition of "api". And to make it worse, this is
> > >>> probably the most important artifact needing a module name. In most
> > >>> cases
> > >>> developers will only need this one: frameworks will handle the
> > >>> implementation part. :)
> > >>> 
> > >>> Robert
> > >>> 
> > >>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> > >>> [2]
> > >>> 
> > >>> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.
> > >>> ht
> > >>> ml
> > >>> 
> > >>> 
> > >>> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY
> > >>> 
> > >>> 
> > >>> wrote:
> >  second option committed in another branch:
> >  
> >  option 1:
> >  http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >  
> >  option 2:
> >  http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> >  
> >  The only part that I'm not sure in option 2 is
> >  org.

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
one associated question I had in mind: how do we document to end users what 
are the module names? Should we add a report to MPIR? And how could this 
report work, particularly on Automatic Module Name?

I'm torn on choosing module name for this component: I think I understand 
Stephen's logic.
Whatever name we choose, there will be a hard step when we move out of 
org.eclipse.aether package in Maven Resolver 2.0.

I'm not sure choosing org.eclipse.aether.* module names for Maven Resolver 1.x 
and org.apache.maven.resolver.* module names for Maven Resolver 2.x will ease 
the transition: whatever the choice, the tricky history of this component will 
make its references tricky.

While we do the trick at Maven artifact coords level, being consistent on the 
same trick at module names.
One idea: perhaps adding the module names in consolidated javadoc groups [1] 
may be a solution to document the hard choice.

Regards,

Hervé

[1] http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/
index.html

Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit :
> Well, you have my opinion. I don't think there is an exemption here
> just because the component has a tricky history, and I personally
> think that any exemption for the package name necessarily applies to
> the module name (since it is now generally agreed that the module name
> derives from the package name).
> 
> Doing otherwise will end up being confusing as more and more people
> name modules after super-packages.
> 
> Stephen
> 
> On 29 May 2017 at 18:46, Robert Scholte  wrote:
> > This makes it an interesting case :)
> > 
> > In short: the name "Aether" is owned by Eclipse and we are not allowed to
> > use it.
> > However, we are allowed to use these packages for compatibility reasons as
> > long as needed.
> > 
> > Module names are not part of this compatibility requirement, so we
> > shouldn't use the name Aether here.
> > Will there be an org.apache.maven.resolver package-based implementation?
> > Not sure, but could very well be.
> > 
> > Based on that I think we're now using the correct/preferred module names.
> > 
> > thanks,
> > Robert
> > 
> > 
> > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
> > 
> >  wrote:
> >> The module name should in almost all cases be the super-package of the
> >> project.
> >> Don't use underscores in the module name unless they are also used in
> >> the package name.
> >> 
> >> If the super-package is "org.apache.maven.resolver.api" then that is
> >> what the module name should be.
> >> But if the super-package is "org.apache.maven.resolver" then that is
> >> what the module name should be.
> >> 
> >> ie. don't add ".api" just because that is what the artifact is called.
> >> Artifact name != module name.
> >> 
> >> However, when I look at the source tree, it seems that the
> >> super-package name is "org.eclipse.aether". If I'm right, then that
> >> should be the module name. And maven-resolver-impl is a problem
> >> because it has two super-packages, but the module name should probably
> >> be "org.eclipse.aether.impl" with the internal package moved under
> >> impl.
> >> 
> >> In summary, ignore the artifact name! Its the package name that
> >> matters when defining the module name.
> >> 
> >> Stephen
> >> 
> >> On 27 May 2017 at 17:43, Robert Scholte  wrote:
> >>> There's no experience with this yet.
> >>> 
> >>> Stephen Colebourne has written to related blogs: module naming[1] and
> >>> modules are not artifacts[2]
> >>> which might suggest that "api" should not be added.
> >>> I do understand the addition of "api". And to make it worse, this is
> >>> probably the most important artifact needing a module name. In most
> >>> cases
> >>> developers will only need this one: frameworks will handle the
> >>> implementation part. :)
> >>> 
> >>> Robert
> >>> 
> >>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> >>> [2]
> >>> 
> >>> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.ht
> >>> ml
> >>> 
> >>> 
> >>> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY
> >>> 
> >>> 
> >>> wrote:
>  second option committed in another branch:
>  
>  option 1:
>  http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
>  
>  option 2:
>  http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
>  
>  The only part that I'm not sure in option 2 is
>  org.apache.maven.resolver.api >
>  org.apache.maven.resolver: is it better to be explicit on the api or
>  implicit?
>  
>  Regards,
>  
>  Hervé
>  
>  Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> > I think I would change the following 2:
> > 
> > org.apache.maven.resolver.connector_basic >
> > org.apache.maven.resolver.connector.basic (in line with transport)
> > org.apache.maven.resolver.test_util >
> > org.apache.maven.resolver.testutil
> > 
> > it's a matter of taste: 

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Stephen Colebourne
Well, you have my opinion. I don't think there is an exemption here
just because the component has a tricky history, and I personally
think that any exemption for the package name necessarily applies to
the module name (since it is now generally agreed that the module name
derives from the package name).

Doing otherwise will end up being confusing as more and more people
name modules after super-packages.

Stephen


On 29 May 2017 at 18:46, Robert Scholte  wrote:
> This makes it an interesting case :)
>
> In short: the name "Aether" is owned by Eclipse and we are not allowed to
> use it.
> However, we are allowed to use these packages for compatibility reasons as
> long as needed.
>
> Module names are not part of this compatibility requirement, so we shouldn't
> use the name Aether here.
> Will there be an org.apache.maven.resolver package-based implementation? Not
> sure, but could very well be.
>
> Based on that I think we're now using the correct/preferred module names.
>
> thanks,
> Robert
>
>
> On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne
>  wrote:
>
>> The module name should in almost all cases be the super-package of the
>> project.
>> Don't use underscores in the module name unless they are also used in
>> the package name.
>>
>> If the super-package is "org.apache.maven.resolver.api" then that is
>> what the module name should be.
>> But if the super-package is "org.apache.maven.resolver" then that is
>> what the module name should be.
>>
>> ie. don't add ".api" just because that is what the artifact is called.
>> Artifact name != module name.
>>
>> However, when I look at the source tree, it seems that the
>> super-package name is "org.eclipse.aether". If I'm right, then that
>> should be the module name. And maven-resolver-impl is a problem
>> because it has two super-packages, but the module name should probably
>> be "org.eclipse.aether.impl" with the internal package moved under
>> impl.
>>
>> In summary, ignore the artifact name! Its the package name that
>> matters when defining the module name.
>>
>> Stephen
>>
>>
>> On 27 May 2017 at 17:43, Robert Scholte  wrote:
>>>
>>> There's no experience with this yet.
>>>
>>> Stephen Colebourne has written to related blogs: module naming[1] and
>>> modules are not artifacts[2]
>>> which might suggest that "api" should not be added.
>>> I do understand the addition of "api". And to make it worse, this is
>>> probably the most important artifact needing a module name. In most cases
>>> developers will only need this one: frameworks will handle the
>>> implementation part. :)
>>>
>>> Robert
>>>
>>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
>>> [2]
>>>
>>> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
>>>
>>>
>>> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY 
>>> wrote:
>>>
 second option committed in another branch:

 option 1:
 http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

 option 2:
 http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

 The only part that I'm not sure in option 2 is
 org.apache.maven.resolver.api >
 org.apache.maven.resolver: is it better to be explicit on the api or
 implicit?

 Regards,

 Hervé

 Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
>
>
> I think I would change the following 2:
>
> org.apache.maven.resolver.connector_basic >
> org.apache.maven.resolver.connector.basic (in line with transport)
> org.apache.maven.resolver.test_util >
> org.apache.maven.resolver.testutil
>
> it's a matter of taste: the underscores look kind of weird, but that's
> probably caused because we've never used them as package names.
>
> And wondering if "api" should be changed, since this is the
> access-module
> and we don't use api in our packages:
> org.apache.maven.resolver.api > org.apache.maven.resolver
>
> Using a property makes it easier to configure the maven-jar-plugin, but
> it
> also makes these constants turn into variables, i.e. you could set them
> via system properties or cmdline args.
> If only we supported something like
>
>
> ${project.properties["AutomaticModuleName"]} ic-Module-Name>
>
> for the rest it's looking good.
>
> thanks
> Robert
>
>
> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> 
>
> wrote:
> > please review and second if you think it's ok:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> >> he he, Java 9 is really coming, with associated real world
> >> questions.
> >>
> >> Maven Artifact Resolver is one of rare Maven components that has a
> >> chance to
> >> become a collection Java 9 modules, si

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Robert Scholte

This makes it an interesting case :)

In short: the name "Aether" is owned by Eclipse and we are not allowed to  
use it.
However, we are allowed to use these packages for compatibility reasons as  
long as needed.


Module names are not part of this compatibility requirement, so we  
shouldn't use the name Aether here.
Will there be an org.apache.maven.resolver package-based implementation?  
Not sure, but could very well be.


Based on that I think we're now using the correct/preferred module names.

thanks,
Robert

On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne  
 wrote:


The module name should in almost all cases be the super-package of the  
project.

Don't use underscores in the module name unless they are also used in
the package name.

If the super-package is "org.apache.maven.resolver.api" then that is
what the module name should be.
But if the super-package is "org.apache.maven.resolver" then that is
what the module name should be.

ie. don't add ".api" just because that is what the artifact is called.
Artifact name != module name.

However, when I look at the source tree, it seems that the
super-package name is "org.eclipse.aether". If I'm right, then that
should be the module name. And maven-resolver-impl is a problem
because it has two super-packages, but the module name should probably
be "org.eclipse.aether.impl" with the internal package moved under
impl.

In summary, ignore the artifact name! Its the package name that
matters when defining the module name.

Stephen


On 27 May 2017 at 17:43, Robert Scholte  wrote:

There's no experience with this yet.

Stephen Colebourne has written to related blogs: module naming[1] and
modules are not artifacts[2]
which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is
probably the most important artifact needing a module name. In most  
cases

developers will only need this one: frameworks will handle the
implementation part. :)

Robert

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html


On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY  


wrote:


second option committed in another branch:

option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

The only part that I'm not sure in option 2 is
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or
implicit?

Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :


I think I would change the following 2:

org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util >  
org.apache.maven.resolver.testutil


it's a matter of taste: the underscores look kind of weird, but that's
probably caused because we've never used them as package names.

And wondering if "api" should be changed, since this is the  
access-module

and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin,  
but

it
also makes these constants turn into variables, i.e. you could set  
them

via system properties or cmdline args.
If only we supported something like

${project.properties["AutomaticModuleName"]}

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY  



wrote:
> please review and second if you think it's ok:
>  
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

>
> Regards,
>
> Hervé
>
> Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
>> he he, Java 9 is really coming, with associated real world  
questions.

>>
>> Maven Artifact Resolver is one of rare Maven components that has a
>> chance to
>> become a collection Java 9 modules, since it was written quite
>> recently
>> and
>> is pure new code as a result of Maven 3 refactoring, then does not
>> have
>> shared package names issues we have with Maven core itself.
>>
>> And since it is expected to be a lib for easy embedding of artifact
>> resolution, making it a collection of Java 9 modules would be not  
only

>> a
>> great opportunity to test Java 9 modules, but it could be useful  
for

>> people
>> using it.
>>
>> Then I'm highly in favor of trying.
>>
>> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible  
right

>> now,
>> without waiting much: I'm pretty sure module names will be obvious,
>> and
>> much
>> better if we define them instead of waiting for automatic names.  
Let's

>> start! MRESOLVER-26 created [1]
>>
>> Then there is the question of making real modules: is it feasible
>> right
>> now?
>> Or would we need a delay to tweak the module descriptors? And that
>> would
>> mean that we need Java 9 to build, even if the generated bytecode
>> remai

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Stephen Colebourne
The module name should in almost all cases be the super-package of the project.
Don't use underscores in the module name unless they are also used in
the package name.

If the super-package is "org.apache.maven.resolver.api" then that is
what the module name should be.
But if the super-package is "org.apache.maven.resolver" then that is
what the module name should be.

ie. don't add ".api" just because that is what the artifact is called.
Artifact name != module name.

However, when I look at the source tree, it seems that the
super-package name is "org.eclipse.aether". If I'm right, then that
should be the module name. And maven-resolver-impl is a problem
because it has two super-packages, but the module name should probably
be "org.eclipse.aether.impl" with the internal package moved under
impl.

In summary, ignore the artifact name! Its the package name that
matters when defining the module name.

Stephen


On 27 May 2017 at 17:43, Robert Scholte  wrote:
> There's no experience with this yet.
>
> Stephen Colebourne has written to related blogs: module naming[1] and
> modules are not artifacts[2]
> which might suggest that "api" should not be added.
> I do understand the addition of "api". And to make it worse, this is
> probably the most important artifact needing a module name. In most cases
> developers will only need this one: frameworks will handle the
> implementation part. :)
>
> Robert
>
> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> [2]
> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
>
>
> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY 
> wrote:
>
>> second option committed in another branch:
>>
>> option 1:
>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
>>
>> option 2:
>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
>>
>> The only part that I'm not sure in option 2 is
>> org.apache.maven.resolver.api >
>> org.apache.maven.resolver: is it better to be explicit on the api or
>> implicit?
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
>>>
>>> I think I would change the following 2:
>>>
>>> org.apache.maven.resolver.connector_basic >
>>> org.apache.maven.resolver.connector.basic (in line with transport)
>>> org.apache.maven.resolver.test_util > org.apache.maven.resolver.testutil
>>>
>>> it's a matter of taste: the underscores look kind of weird, but that's
>>> probably caused because we've never used them as package names.
>>>
>>> And wondering if "api" should be changed, since this is the access-module
>>> and we don't use api in our packages:
>>> org.apache.maven.resolver.api > org.apache.maven.resolver
>>>
>>> Using a property makes it easier to configure the maven-jar-plugin, but
>>> it
>>> also makes these constants turn into variables, i.e. you could set them
>>> via system properties or cmdline args.
>>> If only we supported something like
>>>
>>> ${project.properties["AutomaticModuleName"]}>> ic-Module-Name>
>>>
>>> for the rest it's looking good.
>>>
>>> thanks
>>> Robert
>>>
>>>
>>> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY 
>>>
>>> wrote:
>>> > please review and second if you think it's ok:
>>> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
>>> >
>>> > Regards,
>>> >
>>> > Hervé
>>> >
>>> > Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
>>> >> he he, Java 9 is really coming, with associated real world questions.
>>> >>
>>> >> Maven Artifact Resolver is one of rare Maven components that has a
>>> >> chance to
>>> >> become a collection Java 9 modules, since it was written quite
>>> >> recently
>>> >> and
>>> >> is pure new code as a result of Maven 3 refactoring, then does not
>>> >> have
>>> >> shared package names issues we have with Maven core itself.
>>> >>
>>> >> And since it is expected to be a lib for easy embedding of artifact
>>> >> resolution, making it a collection of Java 9 modules would be not only
>>> >> a
>>> >> great opportunity to test Java 9 modules, but it could be useful for
>>> >> people
>>> >> using it.
>>> >>
>>> >> Then I'm highly in favor of trying.
>>> >>
>>> >> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
>>> >> now,
>>> >> without waiting much: I'm pretty sure module names will be obvious,
>>> >> and
>>> >> much
>>> >> better if we define them instead of waiting for automatic names. Let's
>>> >> start! MRESOLVER-26 created [1]
>>> >>
>>> >> Then there is the question of making real modules: is it feasible
>>> >> right
>>> >> now?
>>> >> Or would we need a delay to tweak the module descriptors? And that
>>> >> would
>>> >> mean that we need Java 9 to build, even if the generated bytecode
>>> >> remains
>>> >> Java 7 compatible, isn't it? Is Maven tooling ready to it?
>>> >> MRESOLVER-27 created to track the issue [2], but I'm not sure this is
>>> >> the
>>> >> right time to do this job, but for the next release after this 1.1.0
>>> >>
>>> >> Regar

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Hervé BOUTEMY
done

Le dimanche 28 mai 2017, 19:54:19 CEST Michael Osipov a écrit :
> Am 2017-05-28 um 17:38 schrieb Hervé BOUTEMY:
> > Michael,
> > 
> > is it ok for you now?
> 
> I prefer option 2. Go ahead with it.
> 
> > Le dimanche 28 mai 2017, 11:16:58 CEST Arnaud Héritier a écrit :
> >> Let's go for option 2
> >> 
> >> Le dim. 28 mai 2017 à 12:44, Robert Scholte  a 
écrit :
> >>> On behalf of the expert group I can confirm we agreed on this solution.
> >>> I don't see any reason why this would change as this topic is marked as
> >>> resolved.
> >>> And I think it is a good sign, for some reason there is/was this rumor
> >>> that Maven doesn't run on J9.
> >>> 
> >>> I second option 2.
> >>> 
> >>> thanks,
> >>> Robert
> >>> 
> >>> On Sun, 28 May 2017 11:15:00 +0200, Michael Osipov 
> >>> 
> >>> wrote:
>  Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:
> > are there seconders for
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> > (aka "option 2")?
>  
>  I'd completely leave it off to 1.x until the expect group with Mark
>  Reinhold has agreed on the disputed points.
>  
>  I don't see a reason to put any effort into a system which is still in
>  constant flux.
>  
> > Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :
> >> good links
> >> yes, with this in mind, "api" is required for artifactId but should
> >> not be
> >> added to module name: good catch, and good experience to share
> >> because
> >> that
> >> was not so obvious
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
> >>> There's no experience with this yet.
> >>> 
> >>> Stephen Colebourne has written to related blogs: module naming[1]
> >>> and
> >>> modules are not artifacts[2]
> >>> which might suggest that "api" should not be added.
> >>> I do understand the addition of "api". And to make it worse, this is
> >>> probably the most important artifact needing a module name. In most
> >>> cases
> >>> developers will only need this one: frameworks will handle the
> >>> implementation part. :)
> >>> 
> >>> Robert
> >>> 
> >>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> >>> [2]
> >>> 
> >>> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.ht
> >>> ml
> >>> 
> >>> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY
> >>> 
> >>> 
> >>> wrote:
>  second option committed in another branch:
> >>> 
>  option 1:
> >>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >>> 
>  option 2:
> >>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> >>> 
>  The only part that I'm not sure in option 2 is
>  org.apache.maven.resolver.api >
>  org.apache.maven.resolver: is it better to be explicit on the api
>  or
>  implicit?
>  
>  Regards,
>  
>  Hervé
>  
>  Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> > I think I would change the following 2:
> > 
> > org.apache.maven.resolver.connector_basic >
> > org.apache.maven.resolver.connector.basic (in line with transport)
> > org.apache.maven.resolver.test_util >
> > org.apache.maven.resolver.testutil
> > 
> > it's a matter of taste: the underscores look kind of weird, but
> > that's
> > probably caused because we've never used them as package names.
> > 
> > And wondering if "api" should be changed, since this is the
> > access-module
> > and we don't use api in our packages:
> > org.apache.maven.resolver.api > org.apache.maven.resolver
> > 
> > Using a property makes it easier to configure the
> > maven-jar-plugin,
> > but
> > it
> > also makes these constants turn into variables, i.e. you could set
> > them
> > via system properties or cmdline args.
> > If only we supported something like
> >>> 
> >>> ${project.properties["AutomaticModuleName"]} >>> 
> > to
> > mat ic-Module-Name>
> > 
> > for the rest it's looking good.
> > 
> > thanks
> > Robert
> > 
> > 
> > On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> > 
> > 
> > wrote:
> >> please review and second if you think it's ok:
> >>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >>> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> >>> he he, Java 9 is really coming, with associated real world
> >>> questions.
> >>> 
> >>> Maven Artifact Reso

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Michael Osipov

Am 2017-05-28 um 17:38 schrieb Hervé BOUTEMY:

Michael,

is it ok for you now?


I prefer option 2. Go ahead with it.


Le dimanche 28 mai 2017, 11:16:58 CEST Arnaud Héritier a écrit :

Let's go for option 2

Le dim. 28 mai 2017 à 12:44, Robert Scholte  a écrit :

On behalf of the expert group I can confirm we agreed on this solution.
I don't see any reason why this would change as this topic is marked as
resolved.
And I think it is a good sign, for some reason there is/was this rumor
that Maven doesn't run on J9.

I second option 2.

thanks,
Robert

On Sun, 28 May 2017 11:15:00 +0200, Michael Osipov 

wrote:

Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:

are there seconders for
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
(aka "option 2")?


I'd completely leave it off to 1.x until the expect group with Mark
Reinhold has agreed on the disputed points.

I don't see a reason to put any effort into a system which is still in
constant flux.


Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :

good links
yes, with this in mind, "api" is required for artifactId but should
not be
added to module name: good catch, and good experience to share because
that
was not so obvious

Regards,

Hervé

Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :

There's no experience with this yet.

Stephen Colebourne has written to related blogs: module naming[1] and
modules are not artifacts[2]
which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is
probably the most important artifact needing a module name. In most
cases
developers will only need this one: frameworks will handle the
implementation part. :)

Robert

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]


http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html


On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY


wrote:

second option committed in another branch:



option 1:

http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7


option 2:

http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7


The only part that I'm not sure in option 2 is
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or
implicit?

Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :

I think I would change the following 2:

org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util >
org.apache.maven.resolver.testutil

it's a matter of taste: the underscores look kind of weird, but
that's
probably caused because we've never used them as package names.

And wondering if "api" should be changed, since this is the
access-module
and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin,
but
it
also makes these constants turn into variables, i.e. you could set
them
via system properties or cmdline args.
If only we supported something like


${project.properties["AutomaticModuleName"]}
to
mat ic-Module-Name>

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY


wrote:

please review and second if you think it's ok:

http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7


Regards,

Hervé

Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :

he he, Java 9 is really coming, with associated real world
questions.

Maven Artifact Resolver is one of rare Maven components that has
a
chance to
become a collection Java 9 modules, since it was written quite


recently


and
is pure new code as a result of Maven 3 refactoring, then does
not


have


shared package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of
artifact
resolution, making it a collection of Java 9 modules would be not


only a


great opportunity to test Java 9 modules, but it could be useful
for
people
using it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible
right
now,
without waiting much: I'm pretty sure module names will be
obvious,


and


much
better if we define them instead of waiting for automatic names.


Let's


start! MRESOLVER-26 created [1]

Then there is the question of making real modules: is it feasible


right


now?
Or would we need a delay to tweak the module descriptors? And
that


would


mean that we need Java 9 to build, even if the generated bytecode
remains
Java 7 compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure
this
is
the
right time to do this job, but for the next release after this
1.1.0

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Hervé BOUTEMY
Michael,

is it ok for you now?

Regards,

Hervé

Le dimanche 28 mai 2017, 11:16:58 CEST Arnaud Héritier a écrit :
> Let's go for option 2
> 
> Le dim. 28 mai 2017 à 12:44, Robert Scholte  a écrit :
> > On behalf of the expert group I can confirm we agreed on this solution.
> > I don't see any reason why this would change as this topic is marked as
> > resolved.
> > And I think it is a good sign, for some reason there is/was this rumor
> > that Maven doesn't run on J9.
> > 
> > I second option 2.
> > 
> > thanks,
> > Robert
> > 
> > On Sun, 28 May 2017 11:15:00 +0200, Michael Osipov 
> > 
> > wrote:
> > > Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:
> > >> are there seconders for
> > >> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> > >> (aka "option 2")?
> > > 
> > > I'd completely leave it off to 1.x until the expect group with Mark
> > > Reinhold has agreed on the disputed points.
> > > 
> > > I don't see a reason to put any effort into a system which is still in
> > > constant flux.
> > > 
> > >> Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :
> > >>> good links
> > >>> yes, with this in mind, "api" is required for artifactId but should
> > >>> not be
> > >>> added to module name: good catch, and good experience to share because
> > >>> that
> > >>> was not so obvious
> > >>> 
> > >>> Regards,
> > >>> 
> > >>> Hervé
> > >>> 
> > >>> Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
> >  There's no experience with this yet.
> >  
> >  Stephen Colebourne has written to related blogs: module naming[1] and
> >  modules are not artifacts[2]
> >  which might suggest that "api" should not be added.
> >  I do understand the addition of "api". And to make it worse, this is
> >  probably the most important artifact needing a module name. In most
> >  cases
> >  developers will only need this one: frameworks will handle the
> >  implementation part. :)
> >  
> >  Robert
> >  
> >  [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> >  [2]
> > 
> > http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
> > 
> >  On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY
> >  
> >  
> >  wrote:
> > > second option committed in another branch:
> > 
> > > option 1:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > 
> > > option 2:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> > 
> > > The only part that I'm not sure in option 2 is
> > > org.apache.maven.resolver.api >
> > > org.apache.maven.resolver: is it better to be explicit on the api or
> > > implicit?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> > >> I think I would change the following 2:
> > >> 
> > >> org.apache.maven.resolver.connector_basic >
> > >> org.apache.maven.resolver.connector.basic (in line with transport)
> > >> org.apache.maven.resolver.test_util >
> > >> org.apache.maven.resolver.testutil
> > >> 
> > >> it's a matter of taste: the underscores look kind of weird, but
> > >> that's
> > >> probably caused because we've never used them as package names.
> > >> 
> > >> And wondering if "api" should be changed, since this is the
> > >> access-module
> > >> and we don't use api in our packages:
> > >> org.apache.maven.resolver.api > org.apache.maven.resolver
> > >> 
> > >> Using a property makes it easier to configure the maven-jar-plugin,
> > >> but
> > >> it
> > >> also makes these constants turn into variables, i.e. you could set
> > >> them
> > >> via system properties or cmdline args.
> > >> If only we supported something like
> > 
> > ${project.properties["AutomaticModuleName"]} > 
> > >> to
> > >> mat ic-Module-Name>
> > >> 
> > >> for the rest it's looking good.
> > >> 
> > >> thanks
> > >> Robert
> > >> 
> > >> 
> > >> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> > >> 
> > >> 
> > >> wrote:
> > >>> please review and second if you think it's ok:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > 
> > >>> Regards,
> > >>> 
> > >>> Hervé
> > >>> 
> > >>> Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> >  he he, Java 9 is really coming, with associated real world
> >  questions.
> >  
> >  Maven Artifact Resolver is one of rare Maven components that has
> >  a
> >  chance to
> >  become a collection Java 9 modules, since it was written quite
> > >> 
> > >> recently
> > >> 
> >  and
> >  is pure new code as a result of Maven 3 refactoring, then does
> >  not
> > >> 
> > >> have
> > >> 
> >  shared pa

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Arnaud Héritier
Let's go for option 2

Le dim. 28 mai 2017 à 12:44, Robert Scholte  a écrit :

> On behalf of the expert group I can confirm we agreed on this solution.
> I don't see any reason why this would change as this topic is marked as
> resolved.
> And I think it is a good sign, for some reason there is/was this rumor
> that Maven doesn't run on J9.
>
> I second option 2.
>
> thanks,
> Robert
>
> On Sun, 28 May 2017 11:15:00 +0200, Michael Osipov 
> wrote:
>
> > Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:
> >> are there seconders for
> >> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> >> (aka "option 2")?
> >
> > I'd completely leave it off to 1.x until the expect group with Mark
> > Reinhold has agreed on the disputed points.
> >
> > I don't see a reason to put any effort into a system which is still in
> > constant flux.
> >
> >> Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :
> >>> good links
> >>> yes, with this in mind, "api" is required for artifactId but should
> >>> not be
> >>> added to module name: good catch, and good experience to share because
> >>> that
> >>> was not so obvious
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
>  There's no experience with this yet.
> 
>  Stephen Colebourne has written to related blogs: module naming[1] and
>  modules are not artifacts[2]
>  which might suggest that "api" should not be added.
>  I do understand the addition of "api". And to make it worse, this is
>  probably the most important artifact needing a module name. In most
>  cases
>  developers will only need this one: frameworks will handle the
>  implementation part. :)
> 
>  Robert
> 
>  [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
>  [2]
> 
> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
> 
> 
>  On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY
>  
> 
>  wrote:
> > second option committed in another branch:
> >
> > option 1:
> >
> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >
> > option 2:
> >
> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> >
> > The only part that I'm not sure in option 2 is
> > org.apache.maven.resolver.api >
> > org.apache.maven.resolver: is it better to be explicit on the api or
> > implicit?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> >> I think I would change the following 2:
> >>
> >> org.apache.maven.resolver.connector_basic >
> >> org.apache.maven.resolver.connector.basic (in line with transport)
> >> org.apache.maven.resolver.test_util >
> >> org.apache.maven.resolver.testutil
> >>
> >> it's a matter of taste: the underscores look kind of weird, but
> >> that's
> >> probably caused because we've never used them as package names.
> >>
> >> And wondering if "api" should be changed, since this is the
> >> access-module
> >> and we don't use api in our packages:
> >> org.apache.maven.resolver.api > org.apache.maven.resolver
> >>
> >> Using a property makes it easier to configure the maven-jar-plugin,
> >> but
> >> it
> >> also makes these constants turn into variables, i.e. you could set
> >> them
> >> via system properties or cmdline args.
> >> If only we supported something like
> >>
> ${project.properties["AutomaticModuleName"]} >> to
> >> mat ic-Module-Name>
> >>
> >> for the rest it's looking good.
> >>
> >> thanks
> >> Robert
> >>
> >>
> >> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> >> 
> >>
> >> wrote:
> >>> please review and second if you think it's ok:
> >>>
> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
>  he he, Java 9 is really coming, with associated real world
>  questions.
> 
>  Maven Artifact Resolver is one of rare Maven components that has a
>  chance to
>  become a collection Java 9 modules, since it was written quite
> >>
> >> recently
> >>
>  and
>  is pure new code as a result of Maven 3 refactoring, then does not
> >>
> >> have
> >>
>  shared package names issues we have with Maven core itself.
> 
>  And since it is expected to be a lib for easy embedding of
>  artifact
>  resolution, making it a collection of Java 9 modules would be not
> >>
> >> only a
> >>
>  great opportunity to test Java 9 modules, but it could be useful
>  for
>  people
>  using it.

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Robert Scholte

On behalf of the expert group I can confirm we agreed on this solution.
I don't see any reason why this would change as this topic is marked as  
resolved.
And I think it is a good sign, for some reason there is/was this rumor  
that Maven doesn't run on J9.


I second option 2.

thanks,
Robert

On Sun, 28 May 2017 11:15:00 +0200, Michael Osipov   
wrote:



Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:

are there seconders for
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
(aka "option 2")?


I'd completely leave it off to 1.x until the expect group with Mark  
Reinhold has agreed on the disputed points.


I don't see a reason to put any effort into a system which is still in  
constant flux.



Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :

good links
yes, with this in mind, "api" is required for artifactId but should  
not be
added to module name: good catch, and good experience to share because  
that

was not so obvious

Regards,

Hervé

Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :

There's no experience with this yet.

Stephen Colebourne has written to related blogs: module naming[1] and
modules are not artifacts[2]
which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is
probably the most important artifact needing a module name. In most  
cases

developers will only need this one: frameworks will handle the
implementation part. :)

Robert

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html


On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY  



wrote:

second option committed in another branch:

option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

The only part that I'm not sure in option 2 is
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or
implicit?

Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :

I think I would change the following 2:

org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util >
org.apache.maven.resolver.testutil

it's a matter of taste: the underscores look kind of weird, but  
that's

probably caused because we've never used them as package names.

And wondering if "api" should be changed, since this is the
access-module
and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin,  
but

it
also makes these constants turn into variables, i.e. you could set  
them

via system properties or cmdline args.
If only we supported something like
${project.properties["AutomaticModuleName"]}

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY


wrote:

please review and second if you think it's ok:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

Regards,

Hervé

Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :

he he, Java 9 is really coming, with associated real world
questions.

Maven Artifact Resolver is one of rare Maven components that has a
chance to
become a collection Java 9 modules, since it was written quite


recently


and
is pure new code as a result of Maven 3 refactoring, then does not


have


shared package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of  
artifact

resolution, making it a collection of Java 9 modules would be not


only a

great opportunity to test Java 9 modules, but it could be useful  
for

people
using it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible  
right

now,
without waiting much: I'm pretty sure module names will be  
obvious,


and


much
better if we define them instead of waiting for automatic names.


Let's


start! MRESOLVER-26 created [1]

Then there is the question of making real modules: is it feasible


right


now?
Or would we need a delay to tweak the module descriptors? And that


would


mean that we need Java 9 to build, even if the generated bytecode
remains
Java 7 compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure this
is
the
right time to do this job, but for the next release after this  
1.1.0


Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :

Hi,

I've got a question from Remi Forax if we could add Java9 module
descriptors to this project.
This will be one of the first which can provide such descriptors


since it


has no required dependencies o

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Michael Osipov

Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:

are there seconders for
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
(aka "option 2")?


I'd completely leave it off to 1.x until the expect group with Mark 
Reinhold has agreed on the disputed points.


I don't see a reason to put any effort into a system which is still in 
constant flux.



Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :

good links
yes, with this in mind, "api" is required for artifactId but should not be
added to module name: good catch, and good experience to share because that
was not so obvious

Regards,

Hervé

Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :

There's no experience with this yet.

Stephen Colebourne has written to related blogs: module naming[1] and
modules are not artifacts[2]
which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is
probably the most important artifact needing a module name. In most cases
developers will only need this one: frameworks will handle the
implementation part. :)

Robert

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html


On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY 

wrote:

second option committed in another branch:

option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

The only part that I'm not sure in option 2 is
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or
implicit?

Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :

I think I would change the following 2:

org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util >
org.apache.maven.resolver.testutil

it's a matter of taste: the underscores look kind of weird, but that's
probably caused because we've never used them as package names.

And wondering if "api" should be changed, since this is the
access-module
and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin, but
it
also makes these constants turn into variables, i.e. you could set them
via system properties or cmdline args.
If only we supported something like
${project.properties["AutomaticModuleName"]}

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY


wrote:

please review and second if you think it's ok:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

Regards,

Hervé

Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :

he he, Java 9 is really coming, with associated real world
questions.

Maven Artifact Resolver is one of rare Maven components that has a
chance to
become a collection Java 9 modules, since it was written quite


recently


and
is pure new code as a result of Maven 3 refactoring, then does not


have


shared package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of artifact
resolution, making it a collection of Java 9 modules would be not


only a


great opportunity to test Java 9 modules, but it could be useful for
people
using it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
now,
without waiting much: I'm pretty sure module names will be obvious,


and


much
better if we define them instead of waiting for automatic names.


Let's


start! MRESOLVER-26 created [1]

Then there is the question of making real modules: is it feasible


right


now?
Or would we need a delay to tweak the module descriptors? And that


would


mean that we need Java 9 to build, even if the generated bytecode
remains
Java 7 compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure this
is
the
right time to do this job, but for the next release after this 1.1.0

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :

Hi,

I've got a question from Remi Forax if we could add Java9 module
descriptors to this project.
This will be one of the first which can provide such descriptors


since it


has no required dependencies other then its own and its package


structure


seems valid with the new Java9 rules.

We haven't discussed this in general yet, but we have several


projects


which are at the bottom of the dependency tree which should
provide


either


a module name or module descriptor when possible.

Do we want to help the community by having already several


libraries


with


a module descriptor?

Or

Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Michael Osipov

Am 2017-05-27 um 11:42 schrieb Hervé BOUTEMY:

Hi,

No objection from me, thanks for keeping the ball rolling.

I tried to improve documentation by adding some useful links to other related
components [1]: I think the current state is better and ok for a release.

One key question now is about Aether wiki content [2]: should we copy it? In a
wiki or in components sources?
I suppose wiki source format is supported by Doxia, then it could be imported
quite easily in sources.


The wiki docs should go into the Resolver site, as apt or md.



And of course, there is the final question: should we do it before the release?


Given the fact that our documentation does not match or dependency 
resolution code, it needs to be reviewed first before being merged. This 
should happen after 1.1.0.



[1] http://maven.apache.org/resolver-archives/resolver-LATEST/

[2] http://wiki.eclipse.org/Aether

Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :

Hi folks,

is there anything holding us back from MRESOLVER 1.1.0?
I'd like to start the release by the end of the week and have it
integrated into Maven 3.5.1.

Any objections?

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing Maven Resolver 1.1.0

2017-05-28 Thread Hervé BOUTEMY
are there seconders for
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
(aka "option 2")?

Regards,

Hervé

Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :
> good links
> yes, with this in mind, "api" is required for artifactId but should not be
> added to module name: good catch, and good experience to share because that
> was not so obvious
> 
> Regards,
> 
> Hervé
> 
> Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
> > There's no experience with this yet.
> > 
> > Stephen Colebourne has written to related blogs: module naming[1] and
> > modules are not artifacts[2]
> > which might suggest that "api" should not be added.
> > I do understand the addition of "api". And to make it worse, this is
> > probably the most important artifact needing a module name. In most cases
> > developers will only need this one: frameworks will handle the
> > implementation part. :)
> > 
> > Robert
> > 
> > [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> > [2]
> > http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
> > 
> > 
> > On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY 
> > 
> > wrote:
> > > second option committed in another branch:
> > > 
> > > option 1:
> > > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > > 
> > > option 2:
> > > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> > > 
> > > The only part that I'm not sure in option 2 is
> > > org.apache.maven.resolver.api >
> > > org.apache.maven.resolver: is it better to be explicit on the api or
> > > implicit?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> > >> I think I would change the following 2:
> > >> 
> > >> org.apache.maven.resolver.connector_basic >
> > >> org.apache.maven.resolver.connector.basic (in line with transport)
> > >> org.apache.maven.resolver.test_util >
> > >> org.apache.maven.resolver.testutil
> > >> 
> > >> it's a matter of taste: the underscores look kind of weird, but that's
> > >> probably caused because we've never used them as package names.
> > >> 
> > >> And wondering if "api" should be changed, since this is the
> > >> access-module
> > >> and we don't use api in our packages:
> > >> org.apache.maven.resolver.api > org.apache.maven.resolver
> > >> 
> > >> Using a property makes it easier to configure the maven-jar-plugin, but
> > >> it
> > >> also makes these constants turn into variables, i.e. you could set them
> > >> via system properties or cmdline args.
> > >> If only we supported something like
> > >> ${project.properties["AutomaticModuleName"]} > >> to
> > >> mat ic-Module-Name>
> > >> 
> > >> for the rest it's looking good.
> > >> 
> > >> thanks
> > >> Robert
> > >> 
> > >> 
> > >> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> > >> 
> > >> 
> > >> wrote:
> > >> > please review and second if you think it's ok:
> > >> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > >> > 
> > >> > Regards,
> > >> > 
> > >> > Hervé
> > >> > 
> > >> > Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> > >> >> he he, Java 9 is really coming, with associated real world
> > >> >> questions.
> > >> >> 
> > >> >> Maven Artifact Resolver is one of rare Maven components that has a
> > >> >> chance to
> > >> >> become a collection Java 9 modules, since it was written quite
> > >> 
> > >> recently
> > >> 
> > >> >> and
> > >> >> is pure new code as a result of Maven 3 refactoring, then does not
> > >> 
> > >> have
> > >> 
> > >> >> shared package names issues we have with Maven core itself.
> > >> >> 
> > >> >> And since it is expected to be a lib for easy embedding of artifact
> > >> >> resolution, making it a collection of Java 9 modules would be not
> > >> 
> > >> only a
> > >> 
> > >> >> great opportunity to test Java 9 modules, but it could be useful for
> > >> >> people
> > >> >> using it.
> > >> >> 
> > >> >> Then I'm highly in favor of trying.
> > >> >> 
> > >> >> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
> > >> >> now,
> > >> >> without waiting much: I'm pretty sure module names will be obvious,
> > >> 
> > >> and
> > >> 
> > >> >> much
> > >> >> better if we define them instead of waiting for automatic names.
> > >> 
> > >> Let's
> > >> 
> > >> >> start! MRESOLVER-26 created [1]
> > >> >> 
> > >> >> Then there is the question of making real modules: is it feasible
> > >> 
> > >> right
> > >> 
> > >> >> now?
> > >> >> Or would we need a delay to tweak the module descriptors? And that
> > >> 
> > >> would
> > >> 
> > >> >> mean that we need Java 9 to build, even if the generated bytecode
> > >> >> remains
> > >> >> Java 7 compatible, isn't it? Is Maven tooling ready to it?
> > >> >> MRESOLVER-27 created to track the issue [2], but I'm not sure this
> > >> >> is
> > >> >> the
> > >> >> right time to do this job, but for the next release after this 1.1.0
> > >> >> 
> > >>

Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Hervé BOUTEMY
good links
yes, with this in mind, "api" is required for artifactId but should not be 
added to module name: good catch, and good experience to share because that 
was not so obvious

Regards,

Hervé

Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
> There's no experience with this yet.
> 
> Stephen Colebourne has written to related blogs: module naming[1] and
> modules are not artifacts[2]
> which might suggest that "api" should not be added.
> I do understand the addition of "api". And to make it worse, this is
> probably the most important artifact needing a module name. In most cases
> developers will only need this one: frameworks will handle the
> implementation part. :)
> 
> Robert
> 
> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> [2]
> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
> 
> 
> On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY 
> 
> wrote:
> > second option committed in another branch:
> > 
> > option 1:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > 
> > option 2:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
> > 
> > The only part that I'm not sure in option 2 is
> > org.apache.maven.resolver.api >
> > org.apache.maven.resolver: is it better to be explicit on the api or
> > implicit?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> >> I think I would change the following 2:
> >> 
> >> org.apache.maven.resolver.connector_basic >
> >> org.apache.maven.resolver.connector.basic (in line with transport)
> >> org.apache.maven.resolver.test_util > org.apache.maven.resolver.testutil
> >> 
> >> it's a matter of taste: the underscores look kind of weird, but that's
> >> probably caused because we've never used them as package names.
> >> 
> >> And wondering if "api" should be changed, since this is the
> >> access-module
> >> and we don't use api in our packages:
> >> org.apache.maven.resolver.api > org.apache.maven.resolver
> >> 
> >> Using a property makes it easier to configure the maven-jar-plugin, but
> >> it
> >> also makes these constants turn into variables, i.e. you could set them
> >> via system properties or cmdline args.
> >> If only we supported something like
> >> ${project.properties["AutomaticModuleName"]} >> mat ic-Module-Name>
> >> 
> >> for the rest it's looking good.
> >> 
> >> thanks
> >> Robert
> >> 
> >> 
> >> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
> >> 
> >> 
> >> wrote:
> >> > please review and second if you think it's ok:
> >> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> >> > 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> >> >> he he, Java 9 is really coming, with associated real world questions.
> >> >> 
> >> >> Maven Artifact Resolver is one of rare Maven components that has a
> >> >> chance to
> >> >> become a collection Java 9 modules, since it was written quite
> >> 
> >> recently
> >> 
> >> >> and
> >> >> is pure new code as a result of Maven 3 refactoring, then does not
> >> 
> >> have
> >> 
> >> >> shared package names issues we have with Maven core itself.
> >> >> 
> >> >> And since it is expected to be a lib for easy embedding of artifact
> >> >> resolution, making it a collection of Java 9 modules would be not
> >> 
> >> only a
> >> 
> >> >> great opportunity to test Java 9 modules, but it could be useful for
> >> >> people
> >> >> using it.
> >> >> 
> >> >> Then I'm highly in favor of trying.
> >> >> 
> >> >> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
> >> >> now,
> >> >> without waiting much: I'm pretty sure module names will be obvious,
> >> 
> >> and
> >> 
> >> >> much
> >> >> better if we define them instead of waiting for automatic names.
> >> 
> >> Let's
> >> 
> >> >> start! MRESOLVER-26 created [1]
> >> >> 
> >> >> Then there is the question of making real modules: is it feasible
> >> 
> >> right
> >> 
> >> >> now?
> >> >> Or would we need a delay to tweak the module descriptors? And that
> >> 
> >> would
> >> 
> >> >> mean that we need Java 9 to build, even if the generated bytecode
> >> >> remains
> >> >> Java 7 compatible, isn't it? Is Maven tooling ready to it?
> >> >> MRESOLVER-27 created to track the issue [2], but I'm not sure this is
> >> >> the
> >> >> right time to do this job, but for the next release after this 1.1.0
> >> >> 
> >> >> Regards,
> >> >> 
> >> >> Hervé
> >> >> 
> >> >> [1] https://issues.apache.org/jira/browse/MRESOLVER-26
> >> >> 
> >> >> [2] https://issues.apache.org/jira/browse/MRESOLVER-27
> >> >> 
> >> >> Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
> >> >> > Hi,
> >> >> > 
> >> >> > I've got a question from Remi Forax if we could add Java9 module
> >> >> > descriptors to this project.
> >> >> > This will be one of the first which can provide such descriptors
> >> >> 
> >> >> since it
> >> >> 
> >> >

Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Robert Scholte

There's no experience with this yet.

Stephen Colebourne has written to related blogs: module naming[1] and  
modules are not artifacts[2]

which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is  
probably the most important artifact needing a module name. In most cases  
developers will only need this one: frameworks will handle the  
implementation part. :)


Robert

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]  
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html



On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY   
wrote:



second option committed in another branch:

option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

The only part that I'm not sure in option 2 is  
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or  
implicit?


Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :

I think I would change the following 2:

org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util > org.apache.maven.resolver.testutil

it's a matter of taste: the underscores look kind of weird, but that's
probably caused because we've never used them as package names.

And wondering if "api" should be changed, since this is the  
access-module

and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin, but  
it

also makes these constants turn into variables, i.e. you could set them
via system properties or cmdline args.
If only we supported something like
${project.properties["AutomaticModuleName"]}

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY  



wrote:
> please review and second if you think it's ok:
> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
>
> Regards,
>
> Hervé
>
> Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
>> he he, Java 9 is really coming, with associated real world questions.
>>
>> Maven Artifact Resolver is one of rare Maven components that has a
>> chance to
>> become a collection Java 9 modules, since it was written quite  
recently

>> and
>> is pure new code as a result of Maven 3 refactoring, then does not  
have

>> shared package names issues we have with Maven core itself.
>>
>> And since it is expected to be a lib for easy embedding of artifact
>> resolution, making it a collection of Java 9 modules would be not  
only a

>> great opportunity to test Java 9 modules, but it could be useful for
>> people
>> using it.
>>
>> Then I'm highly in favor of trying.
>>
>> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
>> now,
>> without waiting much: I'm pretty sure module names will be obvious,  
and

>> much
>> better if we define them instead of waiting for automatic names.  
Let's

>> start! MRESOLVER-26 created [1]
>>
>> Then there is the question of making real modules: is it feasible  
right

>> now?
>> Or would we need a delay to tweak the module descriptors? And that  
would

>> mean that we need Java 9 to build, even if the generated bytecode
>> remains
>> Java 7 compatible, isn't it? Is Maven tooling ready to it?
>> MRESOLVER-27 created to track the issue [2], but I'm not sure this is
>> the
>> right time to do this job, but for the next release after this 1.1.0
>>
>> Regards,
>>
>> Hervé
>>
>> [1] https://issues.apache.org/jira/browse/MRESOLVER-26
>>
>> [2] https://issues.apache.org/jira/browse/MRESOLVER-27
>>
>> Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
>> > Hi,
>> >
>> > I've got a question from Remi Forax if we could add Java9 module
>> > descriptors to this project.
>> > This will be one of the first which can provide such descriptors
>>
>> since it
>>
>> > has no required dependencies other then its own and its package
>>
>> structure
>>
>> > seems valid with the new Java9 rules.
>> >
>> > We haven't discussed this in general yet, but we have several  
projects

>> > which are at the bottom of the dependency tree which should provide
>>
>> either
>>
>> > a module name or module descriptor when possible.
>> >
>> > Do we want to help the community by having already several  
libraries

>>
>> with
>>
>> > a module descriptor?
>> >
>> > Or we could add a Automatic-Module-Name to the MANIFEST.MF, so  
others

>>
>> can
>>
>> > refer to it by its official module name and we can add the  
descriptor

>>
>> once
>>
>> > Java9 has officially been released. (pro: doesn't require Java 9  
:) )

>> >
>> > Or do nothing yet...
>> >
>> > thanks,
>> > Robert
>> >
>> > On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY
>>
>> 
>>
>> > wrote:
>> > > Hi,
>> > >
>> > > No objection from me

Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Hervé BOUTEMY
second option committed in another branch:

option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7

The only part that I'm not sure in option 2 is org.apache.maven.resolver.api > 
org.apache.maven.resolver: is it better to be explicit on the api or implicit?

Regards,

Hervé

Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
> I think I would change the following 2:
> 
> org.apache.maven.resolver.connector_basic >
> org.apache.maven.resolver.connector.basic (in line with transport)
> org.apache.maven.resolver.test_util > org.apache.maven.resolver.testutil
> 
> it's a matter of taste: the underscores look kind of weird, but that's
> probably caused because we've never used them as package names.
> 
> And wondering if "api" should be changed, since this is the access-module
> and we don't use api in our packages:
> org.apache.maven.resolver.api > org.apache.maven.resolver
> 
> Using a property makes it easier to configure the maven-jar-plugin, but it
> also makes these constants turn into variables, i.e. you could set them
> via system properties or cmdline args.
> If only we supported something like
> ${project.properties["AutomaticModuleName"]} ic-Module-Name>
> 
> for the rest it's looking good.
> 
> thanks
> Robert
> 
> 
> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY 
> 
> wrote:
> > please review and second if you think it's ok:
> > http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> >> he he, Java 9 is really coming, with associated real world questions.
> >> 
> >> Maven Artifact Resolver is one of rare Maven components that has a
> >> chance to
> >> become a collection Java 9 modules, since it was written quite recently
> >> and
> >> is pure new code as a result of Maven 3 refactoring, then does not have
> >> shared package names issues we have with Maven core itself.
> >> 
> >> And since it is expected to be a lib for easy embedding of artifact
> >> resolution, making it a collection of Java 9 modules would be not only a
> >> great opportunity to test Java 9 modules, but it could be useful for
> >> people
> >> using it.
> >> 
> >> Then I'm highly in favor of trying.
> >> 
> >> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
> >> now,
> >> without waiting much: I'm pretty sure module names will be obvious, and
> >> much
> >> better if we define them instead of waiting for automatic names. Let's
> >> start! MRESOLVER-26 created [1]
> >> 
> >> Then there is the question of making real modules: is it feasible right
> >> now?
> >> Or would we need a delay to tweak the module descriptors? And that would
> >> mean that we need Java 9 to build, even if the generated bytecode
> >> remains
> >> Java 7 compatible, isn't it? Is Maven tooling ready to it?
> >> MRESOLVER-27 created to track the issue [2], but I'm not sure this is
> >> the
> >> right time to do this job, but for the next release after this 1.1.0
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> [1] https://issues.apache.org/jira/browse/MRESOLVER-26
> >> 
> >> [2] https://issues.apache.org/jira/browse/MRESOLVER-27
> >> 
> >> Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
> >> > Hi,
> >> > 
> >> > I've got a question from Remi Forax if we could add Java9 module
> >> > descriptors to this project.
> >> > This will be one of the first which can provide such descriptors
> >> 
> >> since it
> >> 
> >> > has no required dependencies other then its own and its package
> >> 
> >> structure
> >> 
> >> > seems valid with the new Java9 rules.
> >> > 
> >> > We haven't discussed this in general yet, but we have several projects
> >> > which are at the bottom of the dependency tree which should provide
> >> 
> >> either
> >> 
> >> > a module name or module descriptor when possible.
> >> > 
> >> > Do we want to help the community by having already several libraries
> >> 
> >> with
> >> 
> >> > a module descriptor?
> >> > 
> >> > Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others
> >> 
> >> can
> >> 
> >> > refer to it by its official module name and we can add the descriptor
> >> 
> >> once
> >> 
> >> > Java9 has officially been released. (pro: doesn't require Java 9 :) )
> >> > 
> >> > Or do nothing yet...
> >> > 
> >> > thanks,
> >> > Robert
> >> > 
> >> > On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY
> >> 
> >> 
> >> 
> >> > wrote:
> >> > > Hi,
> >> > > 
> >> > > No objection from me, thanks for keeping the ball rolling.
> >> > > 
> >> > > I tried to improve documentation by adding some useful links to
> >> 
> >> other
> >> 
> >> > > related
> >> > > components [1]: I think the current state is better and ok for a
> >> > > release.
> >> > > 
> >> > > One key question now is about Aether wiki content [2]: should we
> >> 
> >> copy
> >> 
> >> > > it? In a
> >> > > wiki or

Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Robert Scholte

I think I would change the following 2:

org.apache.maven.resolver.connector_basic >  
org.apache.maven.resolver.connector.basic (in line with transport)

org.apache.maven.resolver.test_util > org.apache.maven.resolver.testutil

it's a matter of taste: the underscores look kind of weird, but that's  
probably caused because we've never used them as package names.


And wondering if "api" should be changed, since this is the access-module  
and we don't use api in our packages:

org.apache.maven.resolver.api > org.apache.maven.resolver

Using a property makes it easier to configure the maven-jar-plugin, but it  
also makes these constants turn into variables, i.e. you could set them  
via system properties or cmdline args.

If only we supported something like
${project.properties["AutomaticModuleName"]}

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY   
wrote:



please review and second if you think it's ok:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

Regards,

Hervé

Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :

he he, Java 9 is really coming, with associated real world questions.

Maven Artifact Resolver is one of rare Maven components that has a  
chance to
become a collection Java 9 modules, since it was written quite recently  
and

is pure new code as a result of Maven 3 refactoring, then does not have
shared package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of artifact
resolution, making it a collection of Java 9 modules would be not only a
great opportunity to test Java 9 modules, but it could be useful for  
people

using it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right  
now,
without waiting much: I'm pretty sure module names will be obvious, and  
much

better if we define them instead of waiting for automatic names. Let's
start! MRESOLVER-26 created [1]

Then there is the question of making real modules: is it feasible right  
now?

Or would we need a delay to tweak the module descriptors? And that would
mean that we need Java 9 to build, even if the generated bytecode  
remains

Java 7 compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure this is  
the

right time to do this job, but for the next release after this 1.1.0

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
> Hi,
>
> I've got a question from Remi Forax if we could add Java9 module
> descriptors to this project.
> This will be one of the first which can provide such descriptors  
since it
> has no required dependencies other then its own and its package  
structure

> seems valid with the new Java9 rules.
>
> We haven't discussed this in general yet, but we have several projects
> which are at the bottom of the dependency tree which should provide  
either

> a module name or module descriptor when possible.
>
> Do we want to help the community by having already several libraries  
with

> a module descriptor?
>
> Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others  
can
> refer to it by its official module name and we can add the descriptor  
once

> Java9 has officially been released. (pro: doesn't require Java 9 :) )
>
> Or do nothing yet...
>
> thanks,
> Robert
>
> On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY  


>
> wrote:
> > Hi,
> >
> > No objection from me, thanks for keeping the ball rolling.
> >
> > I tried to improve documentation by adding some useful links to  
other

> > related
> > components [1]: I think the current state is better and ok for a
> > release.
> >
> > One key question now is about Aether wiki content [2]: should we  
copy

> > it? In a
> > wiki or in components sources?
> > I suppose wiki source format is supported by Doxia, then it could be
> > imported
> > quite easily in sources.
> >
> > And of course, there is the final question: should we do it before  
the

> > release?
> >
> > Regards,
> >
> > Hervé
> >
> > [1] http://maven.apache.org/resolver-archives/resolver-LATEST/
> >
> > [2] http://wiki.eclipse.org/Aether
> >
> > Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
> >> Hi folks,
> >>
> >> is there anything holding us back from MRESOLVER 1.1.0?
> >> I'd like to start the release by the end of the week and have it
> >> integrated into Maven 3.5.1.
> >>
> >> Any objections?
> >>
> >> Michael
> >>
> >>  
-

> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >  
-

> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For ad

Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Hervé BOUTEMY
please review and second if you think it's ok:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7

Regards,

Hervé

Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
> he he, Java 9 is really coming, with associated real world questions.
> 
> Maven Artifact Resolver is one of rare Maven components that has a chance to
> become a collection Java 9 modules, since it was written quite recently and
> is pure new code as a result of Maven 3 refactoring, then does not have
> shared package names issues we have with Maven core itself.
> 
> And since it is expected to be a lib for easy embedding of artifact
> resolution, making it a collection of Java 9 modules would be not only a
> great opportunity to test Java 9 modules, but it could be useful for people
> using it.
> 
> Then I'm highly in favor of trying.
> 
> Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right now,
> without waiting much: I'm pretty sure module names will be obvious, and much
> better if we define them instead of waiting for automatic names. Let's
> start! MRESOLVER-26 created [1]
> 
> Then there is the question of making real modules: is it feasible right now?
> Or would we need a delay to tweak the module descriptors? And that would
> mean that we need Java 9 to build, even if the generated bytecode remains
> Java 7 compatible, isn't it? Is Maven tooling ready to it?
> MRESOLVER-27 created to track the issue [2], but I'm not sure this is the
> right time to do this job, but for the next release after this 1.1.0
> 
> Regards,
> 
> Hervé
> 
> [1] https://issues.apache.org/jira/browse/MRESOLVER-26
> 
> [2] https://issues.apache.org/jira/browse/MRESOLVER-27
> 
> Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
> > Hi,
> > 
> > I've got a question from Remi Forax if we could add Java9 module
> > descriptors to this project.
> > This will be one of the first which can provide such descriptors since it
> > has no required dependencies other then its own and its package structure
> > seems valid with the new Java9 rules.
> > 
> > We haven't discussed this in general yet, but we have several projects
> > which are at the bottom of the dependency tree which should provide either
> > a module name or module descriptor when possible.
> > 
> > Do we want to help the community by having already several libraries with
> > a module descriptor?
> > 
> > Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others can
> > refer to it by its official module name and we can add the descriptor once
> > Java9 has officially been released. (pro: doesn't require Java 9 :) )
> > 
> > Or do nothing yet...
> > 
> > thanks,
> > Robert
> > 
> > On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY 
> > 
> > wrote:
> > > Hi,
> > > 
> > > No objection from me, thanks for keeping the ball rolling.
> > > 
> > > I tried to improve documentation by adding some useful links to other
> > > related
> > > components [1]: I think the current state is better and ok for a
> > > release.
> > > 
> > > One key question now is about Aether wiki content [2]: should we copy
> > > it? In a
> > > wiki or in components sources?
> > > I suppose wiki source format is supported by Doxia, then it could be
> > > imported
> > > quite easily in sources.
> > > 
> > > And of course, there is the final question: should we do it before the
> > > release?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > [1] http://maven.apache.org/resolver-archives/resolver-LATEST/
> > > 
> > > [2] http://wiki.eclipse.org/Aether
> > > 
> > > Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
> > >> Hi folks,
> > >> 
> > >> is there anything holding us back from MRESOLVER 1.1.0?
> > >> I'd like to start the release by the end of the week and have it
> > >> integrated into Maven 3.5.1.
> > >> 
> > >> Any objections?
> > >> 
> > >> Michael
> > >> 
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Robert Scholte
On Sat, 27 May 2017 13:24:47 +0200, Hervé BOUTEMY   
wrote:



he he, Java 9 is really coming, with associated real world questions.

Maven Artifact Resolver is one of rare Maven components that has a  
chance to
become a collection Java 9 modules, since it was written quite recently  
and is
pure new code as a result of Maven 3 refactoring, then does not have  
shared

package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of artifact
resolution, making it a collection of Java 9 modules would be not only a  
great
opportunity to test Java 9 modules, but it could be useful for people  
using

it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right now,
without waiting much: I'm pretty sure module names will be obvious, and  
much
better if we define them instead of waiting for automatic names. Let's  
start!

MRESOLVER-26 created [1]


This was indeed the approach I had in mind right now :)



Then there is the question of making real modules: is it feasible right  
now?
Or would we need a delay to tweak the module descriptors? And that would  
mean
that we need Java 9 to build, even if the generated bytecode remains  
Java 7

compatible, isn't it? Is Maven tooling ready to it?


The module-info.java MUST be compiled with Java 9  
(source/target/release=9), while the rest of the classes can stay at a  
lower version.
This implies 2 separate executions as described on the  
maven-compler-plugin page[1]. Let's start doing this after the official  
release of J9


thanks,
Robert

[1]  
http://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html




MRESOLVER-27 created to track the issue [2], but I'm not sure this is the
right time to do this job, but for the next release after this 1.1.0

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :

Hi,

I've got a question from Remi Forax if we could add Java9 module
descriptors to this project.
This will be one of the first which can provide such descriptors since  
it
has no required dependencies other then its own and its package  
structure

seems valid with the new Java9 rules.

We haven't discussed this in general yet, but we have several projects
which are at the bottom of the dependency tree which should provide  
either

a module name or module descriptor when possible.

Do we want to help the community by having already several libraries  
with

a module descriptor?

Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others  
can
refer to it by its official module name and we can add the descriptor  
once

Java9 has officially been released. (pro: doesn't require Java 9 :) )

Or do nothing yet...

thanks,
Robert

On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY  



wrote:
> Hi,
>
> No objection from me, thanks for keeping the ball rolling.
>
> I tried to improve documentation by adding some useful links to other
> related
> components [1]: I think the current state is better and ok for a  
release.

>
> One key question now is about Aether wiki content [2]: should we copy
> it? In a
> wiki or in components sources?
> I suppose wiki source format is supported by Doxia, then it could be
> imported
> quite easily in sources.
>
> And of course, there is the final question: should we do it before the
> release?
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/resolver-archives/resolver-LATEST/
>
> [2] http://wiki.eclipse.org/Aether
>
> Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
>> Hi folks,
>>
>> is there anything holding us back from MRESOLVER 1.1.0?
>> I'd like to start the release by the end of the week and have it
>> integrated into Maven 3.5.1.
>>
>> Any objections?
>>
>> Michael
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Hervé BOUTEMY
he he, Java 9 is really coming, with associated real world questions.

Maven Artifact Resolver is one of rare Maven components that has a chance to 
become a collection Java 9 modules, since it was written quite recently and is 
pure new code as a result of Maven 3 refactoring, then does not have shared 
package names issues we have with Maven core itself.

And since it is expected to be a lib for easy embedding of artifact 
resolution, making it a collection of Java 9 modules would be not only a great 
opportunity to test Java 9 modules, but it could be useful for people using 
it.

Then I'm highly in favor of trying.

Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right now, 
without waiting much: I'm pretty sure module names will be obvious, and much 
better if we define them instead of waiting for automatic names. Let's start! 
MRESOLVER-26 created [1]

Then there is the question of making real modules: is it feasible right now? 
Or would we need a delay to tweak the module descriptors? And that would mean 
that we need Java 9 to build, even if the generated bytecode remains Java 7 
compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure this is the 
right time to do this job, but for the next release after this 1.1.0

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MRESOLVER-26

[2] https://issues.apache.org/jira/browse/MRESOLVER-27

Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
> Hi,
> 
> I've got a question from Remi Forax if we could add Java9 module
> descriptors to this project.
> This will be one of the first which can provide such descriptors since it
> has no required dependencies other then its own and its package structure
> seems valid with the new Java9 rules.
> 
> We haven't discussed this in general yet, but we have several projects
> which are at the bottom of the dependency tree which should provide either
> a module name or module descriptor when possible.
> 
> Do we want to help the community by having already several libraries with
> a module descriptor?
> 
> Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others can
> refer to it by its official module name and we can add the descriptor once
> Java9 has officially been released. (pro: doesn't require Java 9 :) )
> 
> Or do nothing yet...
> 
> thanks,
> Robert
> 
> On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY 
> 
> wrote:
> > Hi,
> > 
> > No objection from me, thanks for keeping the ball rolling.
> > 
> > I tried to improve documentation by adding some useful links to other
> > related
> > components [1]: I think the current state is better and ok for a release.
> > 
> > One key question now is about Aether wiki content [2]: should we copy
> > it? In a
> > wiki or in components sources?
> > I suppose wiki source format is supported by Doxia, then it could be
> > imported
> > quite easily in sources.
> > 
> > And of course, there is the final question: should we do it before the
> > release?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] http://maven.apache.org/resolver-archives/resolver-LATEST/
> > 
> > [2] http://wiki.eclipse.org/Aether
> > 
> > Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
> >> Hi folks,
> >> 
> >> is there anything holding us back from MRESOLVER 1.1.0?
> >> I'd like to start the release by the end of the week and have it
> >> integrated into Maven 3.5.1.
> >> 
> >> Any objections?
> >> 
> >> Michael
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Robert Scholte

Hi,

I've got a question from Remi Forax if we could add Java9 module  
descriptors to this project.
This will be one of the first which can provide such descriptors since it  
has no required dependencies other then its own and its package structure  
seems valid with the new Java9 rules.


We haven't discussed this in general yet, but we have several projects  
which are at the bottom of the dependency tree which should provide either  
a module name or module descriptor when possible.


Do we want to help the community by having already several libraries with  
a module descriptor?


Or we could add a Automatic-Module-Name to the MANIFEST.MF, so others can  
refer to it by its official module name and we can add the descriptor once  
Java9 has officially been released. (pro: doesn't require Java 9 :) )


Or do nothing yet...

thanks,
Robert

On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY   
wrote:



Hi,

No objection from me, thanks for keeping the ball rolling.

I tried to improve documentation by adding some useful links to other  
related

components [1]: I think the current state is better and ok for a release.

One key question now is about Aether wiki content [2]: should we copy  
it? In a

wiki or in components sources?
I suppose wiki source format is supported by Doxia, then it could be  
imported

quite easily in sources.

And of course, there is the final question: should we do it before the  
release?


Regards,

Hervé

[1] http://maven.apache.org/resolver-archives/resolver-LATEST/

[2] http://wiki.eclipse.org/Aether

Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :

Hi folks,

is there anything holding us back from MRESOLVER 1.1.0?
I'd like to start the release by the end of the week and have it
integrated into Maven 3.5.1.

Any objections?

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing Maven Resolver 1.1.0

2017-05-27 Thread Hervé BOUTEMY
Hi,

No objection from me, thanks for keeping the ball rolling.

I tried to improve documentation by adding some useful links to other related 
components [1]: I think the current state is better and ok for a release.

One key question now is about Aether wiki content [2]: should we copy it? In a 
wiki or in components sources?
I suppose wiki source format is supported by Doxia, then it could be imported 
quite easily in sources.

And of course, there is the final question: should we do it before the release?

Regards,

Hervé

[1] http://maven.apache.org/resolver-archives/resolver-LATEST/

[2] http://wiki.eclipse.org/Aether

Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
> Hi folks,
> 
> is there anything holding us back from MRESOLVER 1.1.0?
> I'd like to start the release by the end of the week and have it
> integrated into Maven 3.5.1.
> 
> Any objections?
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org