>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]
