are there seconders for http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7 (aka "option 2")?
Regards, Hervé 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
