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