maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Releasing Maven Resolver 1.1.0
Date Tue, 30 May 2017 18:16:59 GMT
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 <rfscholte@apache.org>  
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  
> <herve.boutemy@free.fr> 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 <rfscholte@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
>>> > > >
>>> > > > <scolebourne@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 <rfscholte@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.boutemy@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.boutemy@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.boutemy@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-unsubscribe@maven.apache.org
>>> > > >>>>> >> > >> For additional commands,
e-mail:  
>>> dev-help@maven.apache.org
>>> > > >>>>> >>
>>> > > >>>>> >>  
>>> ---------------------------------------------------------------
>>> > > >>>>> >> --
>>> > > >>>>> >> --
>>> > > >>>>> >> --
>>> > > >>>>> >>
>>> > > >>>>> >> > > To unsubscribe, e-mail:  
>>> dev-unsubscribe@maven.apache.org
>>> > > >>>>> >> > > For additional commands, e-mail:
 
>>> dev-help@maven.apache.org
>>> > > >>>>> >> >
>>> > > >>>>> >> >  
>>> -------------------------------------------------------------
>>> > > >>>>> >> > --
>>> > > >>>>> >> > --
>>> > > >>>>> >> > ----
>>> > > >>>>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > >>>>> >> > For additional commands, e-mail:
 
>>> dev-help@maven.apache.org
>>> > > >>>>> >>
>>> > > >>>>> >>  
>>> ---------------------------------------------------------------
>>> > > >>>>> >> --
>>> > > >>>>> >> --
>>> > > >>>>> >> --
>>> > > >>>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > >>>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >>>>> >
>>> > > >>>>> >  
>>> ----------------------------------------------------------------
>>> > > >>>>> > --
>>> > > >>>>> > --
>>> > > >>>>> > -
>>> > > >>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > >>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >>>>
>>> > > >>>>  
>>> -------------------------------------------------------------------
>>> > > >>>> --
>>> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> > > >> For additional commands, e-mail: dev-help@maven.apache.org
>>> > >
>>> > >  
>>> ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message