Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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?

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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/

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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.

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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 >

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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

Re: Releasing Maven Resolver 1.1.0

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