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-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"]}< > > >>>>> /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/d1724 > > >>>>> > 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=link&; > > >> ut > > >> m_campaign=sig-email&utm_content=webmail" target="_blank"><img > > >> > > >> src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-ora > > >> 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=link&; > > >> 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
