I removed the test-util module: yes, not expected to be a runtime dependency. And this offers the opportunity to put the jar plugin configuration in a "java9-module" profile
but I kept module name in javadoc group: we're not building with JDK 9 (and it currently does not work, requires some tuning), need a solution waiting for real Java 9 modules with JDK 9 javadoc output Regards, Hervé Le mardi 30 mai 2017, 20:16:59 CEST Robert Scholte a écrit : > I'm having my doubts if we should add the module name in the title of > Javadoc. > > Have a look at the Java 9 javadoc, which has a lot of module info "out of > the box". > > Robert > > On Tue, 30 May 2017 07:58:54 +0200, Robert Scholte <[email protected]> > > wrote: > > How about ignoring the testutil? It should never become a runtime > > dependency, so I don't expect any project will refer to it, hence why > > give it a module name? > > > > Robert > > > > On Tue, 30 May 2017 01:26:52 +0200, Hervé BOUTEMY > > > > <[email protected]> wrote: > >> 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 <[email protected]> > >>> > >>> 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 > >>> > > > > >>> > > > <[email protected]> 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 <[email protected]> > >>> > >>> 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 > >>> > > >>> <[email protected]> > >>> > > >>> > >>> > > >>> 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 > >>> > > >>>>> <[email protected]> > >>> > > >>>>> > >>> > > >>>>> 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 > >>> > > >>>>> >> > >>> > > >>>>> >> <[email protected]> > >>> > > >>>>> >> > >>> > > >>>>> >> > 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: > >>> [email protected] > >>> > >>> > > >>>>> >> > >> For additional commands, e-mail: > >>> [email protected] > >>> > >>> > >>> --------------------------------------------------------------- > >>> > >>> > > >>>>> >> -- > >>> > > >>>>> >> -- > >>> > > >>>>> >> -- > >>> > > >>>>> >> > >>> > > >>>>> >> > > To unsubscribe, e-mail: > >>> [email protected] > >>> > >>> > > >>>>> >> > > For additional commands, e-mail: > >>> [email protected] > >>> > >>> > >>> ------------------------------------------------------------- > >>> > >>> > > >>>>> >> > -- > >>> > > >>>>> >> > -- > >>> > > >>>>> >> > ---- > >>> > > >>>>> >> > To unsubscribe, e-mail: [email protected] > >>> > >>> > > >>>>> >> > For additional commands, e-mail: > >>> [email protected] > >>> > >>> > >>> --------------------------------------------------------------- > >>> > >>> > > >>>>> >> -- > >>> > > >>>>> >> -- > >>> > > >>>>> >> -- > >>> > > >>>>> >> To unsubscribe, e-mail: [email protected] > >>> > > >>>>> >> For additional commands, e-mail: [email protected] > >>> > >>> ---------------------------------------------------------------- > >>> > >>> > > >>>>> > -- > >>> > > >>>>> > -- > >>> > > >>>>> > - > >>> > > >>>>> > To unsubscribe, e-mail: [email protected] > >>> > > >>>>> > For additional commands, e-mail: [email protected] > >>> > >>> ------------------------------------------------------------------- > >>> > >>> > > >>>> -- > >>> > > >>>> To unsubscribe, e-mail: [email protected] > >>> > > >>>> For additional commands, e-mail: [email protected]<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: [email protected] > >>> > > >> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> > >>> > > To unsubscribe, e-mail: [email protected] > >>> > > For additional commands, e-mail: [email protected] > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: [email protected] > >>> > For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
