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