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"]}</Automatic-Module-Name>

for the rest it's looking good.

thanks
Robert


On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY <herve.bout...@free.fr> 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 <herve.bout...@free.fr>
>
> 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

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

Reply via email to