Let's go for option 2 Le dim. 28 mai 2017 à 12:44, Robert Scholte <rfscho...@apache.org> 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 <micha...@apache.org> > 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 > >>>> <herve.bout...@free.fr> > >>>> > >>>> 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 > >>>>>> <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 > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
