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