Actually, I have defined both a repository and a plugin repository - both with central as their I'd.
As I mentioned earlier - there are a few maven-plugin poms that are continually pulled from maven's repository (the default one, not my internal repository). What now? -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Thu 4/13/2006 6:49 PM To: Maven Users List Subject: RE: use of proxies Hi, Note that there are two types of repositories (as was pointed out earlier in this thread): <repository> -- holds "library" jars and <pluginRepository> -- holds "plugin" jars I believe that to completely disable downloading of *libraries* from the standard "library" repository hosted by ibiblio (and aliased from repo1.maven.org) you just define a <repository> with id="central". This overrides the standard definition. Defining a repository with any other id just adds another possible location for maven to check. In order to disable downloading of *plugins* from the standard repository, you need to define a <pluginRepository> with id=central. It looks to me like you've done the first of these, but not the second, with the result that maven is still trying to download *plugins* from repo1.maven.org. Of course if you disable access to the internet for maven plugins, you'll need to install every plugin that you need into your local plugin repository, including things like maven-resources-plugin, maven-compiler-plugin, etc. The maven "distribution" that is available for download only contains the minimal core of maven; to do anything practical with it extra plugins are needed (which get downloaded as needed). I'm not sure how marking a repository as a "mirror" fits in here. Please note that I'm not an expert in this area; I'm still on the maven learning curve. All the above is subject to correction by those who know maven better... Regards, Simon On Thu, 2006-04-13 at 18:13 -0400, EJ Ciramella wrote: > So it seems there's no way to STOP maven from pulling these resources from > the web instead of my server? > > -----Original Message----- > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 3:30 PM > To: Maven Users List > Subject: RE: use of proxies > > 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]
