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]
