I agree that what I need is Maven Proxy, so I can serve the plugins and artifacts internally and at the same time, get the ones I don't have from the internet. But suppose I'm not connected to the internet, or if the policy is to control what artifacts exactly developers get to their local repositories. The settings I've described are outlined and explained in the (latest) book Better Builds with Maven (M2) (http://www.mergere.com/m2book_download.jsp) where the authors (Vincent Massol et.al) recommend overriding central in order to implement an internal remote repository. As strange as it may sound, at this stage it would be perfectly normal for Maven to fail if I don't have the artifact or plugin requested in my internal remote repository. Perhaps the issue I'm pointing is that Maven should allow this scenario (and I'm sure it does!), the issue is not the fact that I can rely permanently on central and my local repository. The other thing to consider in the example presented is that the plugin in question is just 'clean' (mickey mouse goal!).
This won't work because it will fail to find its plugins there unless youve primed it already The truth is that when I move all the contents of my intended internal remote repository back to my local repository, Maven runs fine. This means that for everything Maven needs for a clean is already downloaded. The comment I made literally: I'm about to give up on maven! was because of the frustration because of the lack of M2 documentation. I'm a fan of Maven, don't get me wrong, and in my organisation, I've been a good promoter and evangelist. Some people suggested the upgrade and they looked to me in order to see if it was feasible. We had to stick to M1, even the documentation site of M1 is better organised and gets most of my answers faster than M2. Honestly, I don't like this mini-guides business, some of the links promise answers to interesting things but I get disappointed when I click on them, in many cases there was only a paragraph of basic stuff. Cheers, Gustavo Brad Davis <[EMAIL PROTECTED]> 18/05/2006 17:42 Please respond to "Maven Users List" <[email protected]> To Maven Users List <[email protected]> cc Subject Re: Internal remote repository setup in Maven 2 Gustavo Valle wrote: > <repositories> > <repository> > <id>central</id> > <url>http://localhost:8080/maven</url> > </repository> > </repositories> > > <pluginRepositories> > <pluginRepository> > <id>central</id> > <url>http://localhost:8080/maven</url> > </pluginRepository> > </pluginRepositories> > > I believe by doing this you are overriding the default location for the central repository, and forcing maven to look for everything on localhost. This won't work because it will fail to find its plugins there unless youve primed it already. What you want, from what you've described is a web app that will act as a caching Maven repository. Maven won't do this itself. If you override the central repository then the override location(s) are the only places maven will look for artifacts. The solution is Maven Proxy from codehaus. When you request an artifact from Maven Proxy, it looks at a local (to it) repository and serves it from there, or if it can't, goes to an actual remote repository to fetch it. Sadly, the site is down currently, and likely till the end of the week. The google cache of the main page is here: http://66.102.7.104/search?q=cache:zfDNHXmX7sIJ:maven-proxy.codehaus.org/+maven+proxy+site:codehaus.org&hl=en&lr=&client=firefox-a&strip=1 Personally I recommend using an installed copy of Maven Proxy as a mirror for central (specified either in your POM or your settings.xml) and using a seperate internal repository for internally developed projects. Brad --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please consider our environment before printing this email. WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately. It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments. This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision. Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency. Westpac Banking Corporation ABN 33 007 457 141.
