maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "EJ Ciramella" <ejcirame...@upromise.com>
Subject RE: use of proxies
Date Mon, 17 Apr 2006 19:21:26 GMT
So what do I have to do to submit this request?  Is there anything or is this all expected
behavior? 

-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com] 
Sent: Friday, April 14, 2006 10:48 AM
To: Maven Users List
Subject: Re: use of proxies

I think the problem is that some of these Maven poms are defining new
Repos which are added to the Repos list when they are added as
dependencies.

maven-help-plugin-2.0 has none defined
but it specifies maven-plugin-parent-2.0 as a dependency which specifies

  <repositories>
    <repository>
      <id>snapshots</id>
      <name>Maven Central Development Repository</name>
      <url>http://snapshots.maven.codehaus.org/maven2</url>
      <releases>
        <enabled>false</enabled>
      </releases>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>snapshots</id>
      <name>Maven Central Plugins Development Repository</name>
      <url>http://snapshots.maven.codehaus.org/maven2</url>
      <releases>
        <enabled>false</enabled>
      </releases>
    </pluginRepository>
  </pluginRepositories>

See here:
http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom

And then it has a bunch of other dependencies, which all have their
own poms and dependencies etc... So in all likelihood, somewhere in
that chain, I'm guessing that you are getting several new Repos and
PluginRepos added to your list.

This is certainly a bug in those poms. We've seen this before and I
believe it was agreed that it was not proper for hosted poms to
add/change Repos on the user out of the blue. It would be great if
there was an easy code solution to this problem, but I haven't looked
into it, and at the time the fix was to simply repair that one
specific pom.

So if we can find all the poms like this on Central and open a bunch
of MEV Jira bugs, Carlos will love us (not), but it should get rid of
your problems, EJ.

Wayne

On 4/14/06, EJ Ciramella <ejciramella@upromise.com> wrote:
> Could people just try deleting this helper pom:
>
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-help-plugin/2.0/maven-help-plugin-2.0.pom
> 1K downloaded
>
> And re-run some goal?  These are the ones that keep coming from repo1.
>
> Again, here are the steps to recreate:
>
> I have these two repositories:
>    <repositories>
>                <repository>
>                        <id>local</id>
>                        <name>local-repository</name>
>                        <url>file:thirdparty/repository</url>
>                </repository>
>                <repository>
>                        <id>central</id>
>                        <name>Upromise Local Repository</name>
>                        <layout>default</layout>
>                        <url>http://build.corp.upromise.com/mavenrepository</url>
>                </repository>
>        </repositories>
>
>    <pluginRepositories>
>        <pluginRepository>
>                        <id>local-central</id>
>                        <name>main</name>
>                        <layout>default</layout>
>                        <url>http://build.corp.upromise.com/mavenrepository</url>
>        </pluginRepository>
>    </pluginRepositories>
>
> I delete my .m2/repository directory and then run "mvn process-resources"
>
> I see the following pulled down from repo1 (and many more pulled correctly from my internal
server):
>
> (it says:[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for
updates from local-central
> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates
from central  before each)
>
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.1/maven-compiler-plugin-2.0.1.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
> 1K downloaded
> Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.1/maven-resources-plugin-2.1.pom
> 888b downloaded
>
>
> -----Original Message-----
> From: Gunther Popp [mailto:Gunther.Popp@web.de]
> Sent: Friday, April 14, 2006 7:16 AM
> To: Maven Users List
> Subject: Re: use of proxies
>
>  >If you use <repository> in your pom instead of a mirror setting, maven
> will add your repo in the search list but won't replace >repo1 by your
> own repo.
>
>  >The mirrors setting is stricter than adding just a new
> central-repository inside the pom
>
> Having said this, I just browsed the source-code again and IMO this is
> not true if two repositories share the same id. If Maven adds an
> internal repo with the id "central" defined in the pom to this list, the
> default repositories with the same id from pom-4.0.0.xml will be
> skipped. Since pluginRepositories and normal repositories are maintained
> in two lists, it is possible to use the id central for both types of
> repositories. But in each of the lists, the id is guaranteed to be unique.
>
> At least, if I understand the code correctly :-)
> (DefaultModelInheritanceAssembler.assembleModelInheritance() and
> ModelUtils.mergeRepositoryLists()).
>
> CU,
>
> Gunther
>
>
>
> Gunther Popp schrieb:
> > You´re right, of course. The mirrors setting is stricter than adding
> > just a new central-repository inside the pom. However, one can only
> > define mirrors in settings.xml. This is, IMO, problematic. If a new
> > developer joins the team, checks out the project from svn, forgets
> > about modifying her local settings.xml and starts hacking, she will
> > use http://repo1.maven.org/maven2.
> >
> > AFAIK, there is no way to force the usage a specific mirror setting in
> > the team. OTHO, if I modify the POM directly, everyone on the team
> > uses the same repository setup by default.
> >
> > But the mirrors should be mentioned as alternative in any case, that´s
> > right.
> >
> > Gunther
> >
> > Emmanuel Venisse schrieb:
> >> If you don't want to use repo1 repository but your own, you must
> >> define a mirror in your settings.xml like this:
> >>
> >> <settings>
> >>   .
> >>   .
> >>   <mirrors>
> >>     <mirror>
> >>       <id>local</id>
> >>       <name>Local Mirror of http://repo1.maven.org/maven2/</name>
> >>       <url>http://localhost/mvnrepos/lib</url>
> >>       <mirrorOf>central</mirrorOf>
> >>     </mirror>
> >>   </mirrors>
> >>   .
> >>   .
> >> </settings>
> >>
> >> If you use <repository> in your pom instead of a mirror setting,
> >> maven will add your repo in the search list but won't replace repo1
> >> by your own repo.
> >>
> >> Emmanuel
> >>
> >> Gunther Popp a écrit :
> >>> Well, Hacks are sometimes the way to go ...  :-) Maybe a future
> >>> Maven version will provide some "official" option to replace the
> >>> standard repo.
> >>>
> >>> Gunther
> >>>
> >>> dan tran schrieb:
> >>>
> >>>> Just want to confirm, Gunther's setup works.  I force a bad missing
> >>>> artifact
> >>>> and maven output shows it only
> >>>> search my internal repo
> >>>>
> >>>>
> >>>> On 4/14/06, dan tran <dantran@gmail.com> wrote:
> >>>>
> >>>>
> >>>>>  Did i mention it is a hacked solution? :-)
> >>>>>
> >>>>> BTW, the way m2 shows build output is very confused, when an missing
> >>>>> artifact occurs,
> >>>>> it shows repo1 got searched first.
> >>>>>
> >>>>> -D
> >>>>>
> >>>>>
> >>>>> On 4/14/06, Gunther Popp <Gunther.Popp@web.de> wrote:
> >>>>>
> >>>>>> Hmm, what´s wrong with my solution? Redefining a repo using
the id
> >>>>>> "central"? This works fine and is, IMO, a normal usage of the
> >>>>>> POM-inheritance of Maven (with pom-4.0.0.xml as implicit parent
> >>>>>> pom).
> >>>>>>
> >>>>>> Changing the hosts file would be necessary on every single developer
> >>>>>> workstation, so I´m not sure if this is really better.
> >>>>>>
> >>>>>> Gunther
> >>>>>>
> >>>>>>
> >>>>>> dan tran schrieb:
> >>>>>>
> >>>>>>> this is  a hacked solution, fixup your hosts file and route
> >>>>>>> repo1.apache.orgto your internal host
> >>>>>>>
> >>>>>>> -D
> >>>>>>>
> >>>>>>>
> >>>>>>> On 4/14/06, Gunther Popp < Gunther.Popp@web.de> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hmm, I´ve been monitoring this thread (and it´s predecessor)
for a
> >>>>>>>>
> >>>>>>
> >>>>>> while
> >>>>>>
> >>>>>>>> am still not sure what´s wrong with your setup. From
all I´ve
> >>>>>>>> read,
> >>>>>>>>
> >>>>>>
> >>>>>> it
> >>>>>>
> >>>>>>>> should work. I´m using internal repositories for a
while now,
> >>>>>>>> without
> >>>>>>>>           any problems. Here´s my definition of repositories
> >>>>>>>> I´m using in my
> >>>>>>>>
> >>>>>>
> >>>>>> POM:
> >>>>>>
> >>>>>>>> <!-- Definition privater Repositories -->
> >>>>>>>> <repositories>
> >>>>>>>>    <repository>
> >>>>>>>>      <id>central</id>
> >>>>>>>>      <name>Privates Repository für externe Bibliotheken</name>
> >>>>>>>>      <url>http://localhost/mvnrepos/lib </url>
> >>>>>>>>      <releases>
> >>>>>>>>        <enabled>true</enabled>
> >>>>>>>>        <updatePolicy>daily</updatePolicy>
> >>>>>>>>      </releases>
> >>>>>>>>      <snapshots>
> >>>>>>>>        <enabled>false</enabled>
> >>>>>>>>      </snapshots>
> >>>>>>>>    </repository>
> >>>>>>>> </repositories>
> >>>>>>>>
> >>>>>>>> <pluginRepositories>
> >>>>>>>>     <pluginRepository>
> >>>>>>>>       <id>central</id>
> >>>>>>>>       <name>Privates Repository für Plugins</name>
> >>>>>>>>       <url>http://localhost/mvnrepos/plugin </url>
> >>>>>>>>       <releases>
> >>>>>>>>         <enabled>true</enabled>
> >>>>>>>>         <updatePolicy>daily</updatePolicy>
> >>>>>>>>       </releases>
> >>>>>>>>       <snapshots>
> >>>>>>>>         <enabled>false</enabled>
> >>>>>>>>       </snapshots>
> >>>>>>>>     </pluginRepository>
> >>>>>>>>   </pluginRepositories>
> >>>>>>>>
> >>>>>>>> Maybe you´ll find a difference to your setup. Just
a note: A
> >>>>>>>>
> >>>>>>
> >>>>>> potential
> >>>>>>
> >>>>>>>> problem arises, if a POM in the repository defines a
parent POM
> >>>>>>>> _and_
> >>>>>>>> redefines the central-repository using
> >>>>>>>> http://repo1.maven.org/maven2,
> >>>>>>>> too. In this case it is possible that Maven still accesses
the
> >>>>>>>>
> >>>>>>
> >>>>>> default
> >>>>>>
> >>>>>>>> repository url to download the parent POMs. But AFAIK
that´s
> >>>>>>>> not true
> >>>>>>>> for the POM of the resources-plugin.
> >>>>>>>>
> >>>>>>>> CU,
> >>>>>>>>
> >>>>>>>> Gunther
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> EJ Ciramella schrieb:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Take about 10 steps back and a deep breath - the
problem is
> >>>>>>>>> that the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> security forces that be don't like the fact that anything
can be
> >>>>>>>>
> >>>>>>
> >>>>>> placed up
> >>>>>>
> >>>>>>>> there ( http://repo1.maven.org/maven2) and then pulled
down.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> In addition to this, why oh why is maven downloading
something
> >>>>>>>>>
> >>>>>>
> >>>>>> remotely
> >>>>>>
> >>>>>>>> that exist within our four walls?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> How do I stop this?
> >>>>>>>>>
> >>>>>>>>> E:\work\foxboro\model>mvn process-resources
> >>>>>>>>> [INFO] Scanning for projects...
> >>>>>>>>> [INFO]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>> [INFO] Building LtyModel
> >>>>>>>>> [INFO]    task-segment: [process-resources]
> >>>>>>>>> [INFO]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>> [INFO] artifact
> >>>>>>>>>
> >>>>>>
> >>>>>> org.apache.maven.plugins:maven-resources-plugin:checking for
updates
> >>>>>> from local-central
> >>>>>>
> >>>>>>>>> [INFO] artifact
> >>>>>>>>>
> >>>>>>
> >>>>>> org.apache.maven.plugins:maven-resources-plugin:checking for
updates
> >>>>>> from central
> >>>>>>
> >>>>>>>>> Downloading:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.1/maven-resources-plugin-2.1.pom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 888b downloaded
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-compiler-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from local-central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-compiler-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Downloading:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.1/maven-compiler-plugin-2.0.1.pom
> >>>>>>
> >>>>>>
> >>>>>>>>> 1K downloaded
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-surefire-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from local-central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-surefire-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Downloading:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.1.3/maven-surefire-plugin-2.1.3.pom
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 1K downloaded
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-javadoc-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from local-central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> [INFO] artifact
> >>>>>>>>> org.apache.maven.plugins:maven-javadoc-plugin:checking
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> for updates from central
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Downloading:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
> >>>>>>
> >>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Gunther Popp [mailto: Gunther.Popp@web.de]
> >>>>>>>>> Sent: Thursday, April 13, 2006 1:51 PM
> >>>>>>>>> To: Maven Users List
> >>>>>>>>> Subject: Re: use of proxies
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The first question is: why?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Sorry, for jumping in here, but a common reason
is to guarantee
> >>>>>>>>> reproducible builds over a fairly long period of
time. For
> >>>>>>>>> example,
> >>>>>>>>>
> >>>>>>
> >>>>>> the
> >>>>>>
> >>>>>>>>> systems I´m engaged with have a typical lifetime
of 15-20 years.
> >>>>>>>>>
> >>>>>>
> >>>>>> When
> >>>>>>
> >>>>>>>>> the software is considered stable after initial
development, a
> >>>>>>>>> team
> >>>>>>>>>
> >>>>>>
> >>>>>> of
> >>>>>>
> >>>>>>>>> maintenance developers will implement enhancements
and fix bugs.
> >>>>>>>>>
> >>>>>>
> >>>>>> These
> >>>>>>
> >>>>>>>>> guys are typically responsible for several systems
and have no
> >>>>>>>>> time
> >>>>>>>>>
> >>>>>>
> >>>>>> to
> >>>>>>
> >>>>>>>>> hassle around with build tools. So the build process
simply
> >>>>>>>>> should
> >>>>>>>>>
> >>>>>>
> >>>>>> work.
> >>>>>>
> >>>>>>>>> You cannot guarantee this, if your build relies
on any form of
> >>>>>>>>>
> >>>>>>
> >>>>>> external
> >>>>>>
> >>>>>>>>> resource that is not under your direct control.
Even if I use
> >>>>>>>>>
> >>>>>>
> >>>>>> explicit
> >>>>>>
> >>>>>>>>> version numbering for plugins and dependencies,
the corresponding
> >>>>>>>>> artifacts simply may disappear on iblio in five
years from
> >>>>>>>>> now. Or,
> >>>>>>>>> another scenario, maybe the repository layout changes
in Maven
> >>>>>>>>> 3 or
> >>>>>>>>>
> >>>>>>
> >>>>>> 4
> >>>>>>
> >>>>>>>>> and "legacy" Maven 2 repositories are only supported
until
> >>>>>>>>> 2010. At
> >>>>>>>>>
> >>>>>>
> >>>>>> this
> >>>>>>
> >>>>>>>>> time it is to expensive and risky to upgrade the
build process
> >>>>>>>>> for a
> >>>>>>>>>             running mission-critical system to a
completely
> >>>>>>>>> new version of
> >>>>>>>>>
> >>>>>>
> >>>>>> Maven.
> >>>>>>
> >>>>>>>>> Nobody will fund this.
> >>>>>>>>>
> >>>>>>>>> So, the only way to prevent this is to use strictly
internal
> >>>>>>>>> repositories. This means additional effort, of course,
and
> >>>>>>>>> only pays
> >>>>>>>>>
> >>>>>>
> >>>>>> off
> >>>>>>
> >>>>>>>>> if you really have use case for it. But these use
cases certainly
> >>>>>>>>>
> >>>>>>
> >>>>>> exist.
> >>>>>>
> >>>>>>>>> CU,
> >>>>>>>>>
> >>>>>>>>> Gunther
> >>>>>>>>>
> >>>>>>>>> Barrie Treloar schrieb:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 4/13/06, EJ Ciramella <ejciramella@upromise.com
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> All I'm attempting to do is prevent builds
from going to the
> >>>>>>>>>>> maven
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>> repository.  I have set up one machine ( build.corp.upromise.com)
> >>>>>>>>
> >>>>>>
> >>>>>> that has
> >>>>>>
> >>>>>>>> everything from my .m2/repository directory (I copied
it there).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> The first question is: why?
> >>>>>>>>>>
> >>>>>>>>>> Maven manages your build dependencies. Use version
numbers in
> >>>>>>>>>> your
> >>>>>>>>>>
> >>>>>>
> >>>>>> pom
> >>>>>>
> >>>>>>>>>> dependencies to lock down what should be used
instead of
> >>>>>>>>>>
> >>>>>>
> >>>>>> restricting
> >>>>>>
> >>>>>>>>>> access to central.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>>
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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


Mime
View raw message