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