commit proposed in a new branch and generated site from this branch published for review: - aggregated javadoc https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html
- API javadoc https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-api/ apidocs/index.html - Implementation javadoc http://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-impl/ apidocs/index.html Regards, Hervé Le mardi 30 mai 2017, 01:05:24 CEST Hervé BOUTEMY a écrit : > another complementary reaction while reviewing consistency between java > package names and modules names: perhaps we should change > org.apache.maven.resolver.testutil > to org.apache.maven.resolver.internal.test.util > > Regards, > > Hervé > > Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit : > > one associated question I had in mind: how do we document to end users > > what > > are the module names? Should we add a report to MPIR? And how could this > > report work, particularly on Automatic Module Name? > > > > I'm torn on choosing module name for this component: I think I understand > > Stephen's logic. > > Whatever name we choose, there will be a hard step when we move out of > > org.eclipse.aether package in Maven Resolver 2.0. > > > > I'm not sure choosing org.eclipse.aether.* module names for Maven Resolver > > 1.x and org.apache.maven.resolver.* module names for Maven Resolver 2.x > > will ease the transition: whatever the choice, the tricky history of this > > component will make its references tricky. > > > > While we do the trick at Maven artifact coords level, being consistent on > > the same trick at module names. > > One idea: perhaps adding the module names in consolidated javadoc groups > > [1] may be a solution to document the hard choice. > > > > Regards, > > > > Hervé > > > > [1] http://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/ > > index.html > > > > Le lundi 29 mai 2017, 21:42:11 CEST Stephen Colebourne a écrit : > > > Well, you have my opinion. I don't think there is an exemption here > > > just because the component has a tricky history, and I personally > > > think that any exemption for the package name necessarily applies to > > > the module name (since it is now generally agreed that the module name > > > derives from the package name). > > > > > > Doing otherwise will end up being confusing as more and more people > > > name modules after super-packages. > > > > > > Stephen > > > > > > On 29 May 2017 at 18:46, Robert Scholte <rfscho...@apache.org> wrote: > > > > This makes it an interesting case :) > > > > > > > > In short: the name "Aether" is owned by Eclipse and we are not allowed > > > > to > > > > use it. > > > > However, we are allowed to use these packages for compatibility > > > > reasons > > > > as > > > > long as needed. > > > > > > > > Module names are not part of this compatibility requirement, so we > > > > shouldn't use the name Aether here. > > > > Will there be an org.apache.maven.resolver package-based > > > > implementation? > > > > Not sure, but could very well be. > > > > > > > > Based on that I think we're now using the correct/preferred module > > > > names. > > > > > > > > thanks, > > > > Robert > > > > > > > > > > > > On Mon, 29 May 2017 18:55:53 +0200, Stephen Colebourne > > > > > > > > <scolebou...@joda.org> wrote: > > > >> The module name should in almost all cases be the super-package of > > > >> the > > > >> project. > > > >> Don't use underscores in the module name unless they are also used in > > > >> the package name. > > > >> > > > >> If the super-package is "org.apache.maven.resolver.api" then that is > > > >> what the module name should be. > > > >> But if the super-package is "org.apache.maven.resolver" then that is > > > >> what the module name should be. > > > >> > > > >> ie. don't add ".api" just because that is what the artifact is > > > >> called. > > > >> Artifact name != module name. > > > >> > > > >> However, when I look at the source tree, it seems that the > > > >> super-package name is "org.eclipse.aether". If I'm right, then that > > > >> should be the module name. And maven-resolver-impl is a problem > > > >> because it has two super-packages, but the module name should > > > >> probably > > > >> be "org.eclipse.aether.impl" with the internal package moved under > > > >> impl. > > > >> > > > >> In summary, ignore the artifact name! Its the package name that > > > >> matters when defining the module name. > > > >> > > > >> Stephen > > > >> > > > >> On 27 May 2017 at 17:43, Robert Scholte <rfscho...@apache.org> wrote: > > > >>> 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-artifact > > > >>> s. > > > >>> 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/d1724e > > > >>>> b7 > > > >>>> > > > >>>> option 2: > > > >>>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804 > > > >>>> d7 > > > >>>> > > > >>>> 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"] > > > >>>>> }< > > > >>>>> /A > > > >>>>> utomat 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/d17 > > > >>>>> > 24 > > > >>>>> > eb > > > >>>>> > 7 > > > >>>>> > > > > >>>>> > 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<div > > > >>>> id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> > > > >> > > > >> <table style="border-top: 1px solid #D3D4DE;"> > > > >> > > > >> <tr> > > > >> <td style="width: 55px; padding-top: 13px;"><a > > > >> > > > >> href="https://www.avast.com/sig-email?utm_medium=email&utm_source=lin > > > >> k& > > > >> ut > > > >> m_campaign=sig-email&utm_content=webmail" target="_blank"><img > > > >> > > > >> src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-o > > > >> ra > > > >> ng > > > >> e-animated-no-repeat-v1.gif" width="46" height="29" style="width: > > > >> 46px; > > > >> height: 29px;" /></a></td>>> > > > >> > > > >> <td style="width: 470px; padding-top: 12px; color: > > > >> #41424e; > > > >> font-size: 13px; font-family: Arial, Helvetica, sans-serif; > > > >> line-height: 18px;">Virus-free. <a > > > >> > > > >> href="https://www.avast.com/sig-email?utm_medium=email&utm_source=lin > > > >> k& > > > >> ut > > > >> m_campaign=sig-email&utm_content=webmail" target="_blank" > > > >> style="color: > > > >> #4453ea;">www.avast.com</a> > > > >> > > > >> </td> > > > >> > > > >> </tr> > > > >> > > > >> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" > > > >> height="1"></a></div> > > > >> > > > >> --------------------------------------------------------------------- > > > >> 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
