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