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