Releasing Maven Resolver 1.1.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Releasing Maven Resolver 1.1.0

Michael Osipov-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing Maven Resolver 1.1.0

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 <[hidden email]>
> >
> > 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing Maven Resolver 1.1.0

Michael Osipov-2
In reply to this post by Michael Osipov-2
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing Maven Resolver 1.1.0

Michael Osipov-2
In reply to this post by Michael Osipov-2
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 <[hidden email]> 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 <[hidden email]>
>>>
>>> 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
>>>>>>> <[hidden email]>
>>>>>>>
>>>>>>> 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
>>>
>>> <Automatic-Module-Name>${project.properties["AutomaticModuleName"]}</Au
>>>
>>>>>>>>> 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
>>>>>>>>> <[hidden email]>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> <[hidden email]>
>>>>>>>>>>>
>>>>>>>>>>>> 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: [hidden email]
>>>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>
>>> --------------------------------------------------------------------
>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>>
>>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>
>>> --------------------------------------------------------------------
>>>
>>>>>>>>>>> -
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>>
>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>> --
>>
>> -----
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing Maven Resolver 1.1.0

Stephen Colebourne
In reply to this post by Hervé BOUTEMY
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 <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>>>>
>>>>>
>>>>> <Automatic-Module-Name>${project.properties["AutomaticModuleName"]}</Automat
>>>>> ic-Module-Name>
>>>>>
>>>>> for the rest it's looking good.
>>>>>
>>>>> thanks
>>>>> Robert
>>>>>
>>>>>
>>>>> On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
>>>>> <[hidden email]>
>>>>>
>>>>> 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
>>>>> >>
>>>>> >> <[hidden email]>
>>>>> >>
>>>>> >> > 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: [hidden email]
>>>>> >> > >> For additional commands, e-mail: [hidden email]
>>>>> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >>
>>>>> >> > > To unsubscribe, e-mail: [hidden email]
>>>>> >> > > For additional commands, e-mail: [hidden email]
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > ---------------------------------------------------------------------
>>>>> >> > To unsubscribe, e-mail: [hidden email]
>>>>> >> > For additional commands, e-mail: [hidden email]
>>>>> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: [hidden email]
>>>>> >> For additional commands, e-mail: [hidden email]
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: [hidden email]
>>>>> > For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]<div
>>>> id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
>>
>> <table style="border-top: 1px solid #D3D4DE;">
>>         <tr>
>>         <td style="width: 55px; padding-top: 13px;"><a
>>
>> href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
>> target="_blank"><img
>>
>> src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
>> width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
>>                 <td style="width: 470px; padding-top: 12px; color:
>> #41424e;
>> font-size: 13px; font-family: Arial, Helvetica, sans-serif;
>> line-height: 18px;">Virus-free. <a
>>
>> href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
>> target="_blank" style="color: #4453ea;">www.avast.com</a>
>>                 </td>
>>         </tr>
>> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
>> height="1"></a></div>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...