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"]}</Auto > >> 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
