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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >>>>>>>>> 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 <[EMAIL PROTECTED] > 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: [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]
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]
>
>
