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]
