Hi Nico, Thanks for your feedback. I have effectively the same problem if I use my proxy-all repo. I followed the threads about risks on plugins updates and I agree that it is better to define the list of validated plugins (in a parent pom for example). The problem is to maintain this pom because I can't ask to the dev teams to do it themself. I don't yet begin to create one but I think I will... I'm feeling at ease to know that I'm not the only one to have those problems ;-)
Arnaud PS: I tested all the patchs for m1 with the trunk and it's working fine. I'll commit them soon. nicolas de loof-2 wrote: > > I myself have this config : > > I have folder-based repositories (hand managed, not included in archiva as > managed repo) for > - private corporate artifacts (release + snapshots) > - restricted libs (sun jar, oracle driver...) > - free libs not available on repo1 OR -soures.jar for existing libs > (spring-xx) > > I have configured an archiva managed repository that proxies > > - my 3 private repos > - repo1.maven.org > - snapshots from apache & codehaus > - java.net repo > > The developpers configure maven2 to use archiva as <mirrorOf>*</mirrorOf> > > If some artifact is missing, I can add the expected repo as proxied or > copy > the expected artifact in my "free libs" repo. > > This config has an issue : > I' writing a corporate POM and deployed a snapshot. For any project to use > it as parent I have to add a repository entry with snapshot enabled, > pointing to my "corporate artifacts" repo. As mirrorOf redirects to > archiva, > this also enables snapshots from apache/codehaus. > This may introduce unexpected snapshots pluginsin the build and make it > unreproductible. > > I encourage users to force the plugin <version> (see recent thread on > list) > to avoid this issue. > > Nico. > > > 2007/4/19, Arnaud HERITIER <[EMAIL PROTECTED]>: >> >> Hi everybody, >> >> I would like to have your feedback about the usage of maven (1 & 2) >> with >> archiva in a corporate environment. >> >> Up until now in a corporate environment I was using by default 5 >> managed >> repositories : >> - corporate-releases : for inhouse releases filled by teams (and by >> continuum 1.1 shortly). >> - corporate-snapshots : for inhouse snapshots filled by the CI. >> - proxy-releases : for the central repository and few others not >> synchronized. >> - proxy-snapshots : for snapshots coming from apache, codehaus and >> more. >> - 3rdparties : for 3rd party editors which don't publish their >> libraries. >> >> I think it is a good separation for repositories because they don't >> have >> the same size (releases vs snapshots) and the same backup policy >> (corporate >> vs proxy). >> The problem with this approach is that we have to deploy a "complex" >> settings.xml for developers. We have to define : >> - several proxies using proxy-releases or proxy-snapshots >> - 5 repositories >> - 5 pluginRepositories >> Another problem is that when maven (1 or 2) tries to download a missing >> dependency it will send several requests to archiva and it can be slow if >> the network isn't enough rapid. This problem occurs often when you have >> to >> update your IDE settings. Maven tries to download X times the javadocs >> and >> sources (but it's useful to have them). >> >> I tried to find a workaroung for that by replacing both proxy >> repositories >> by only one (proxy-all) which proxies at the same time my internal >> repositories and the releases and snapshots outside of the company. >> It's working find and I have better performances because maven send >> only >> one request to archiva. My settings are very reduced because I just have >> to >> define one proxy (with *), one repository and one pluginRepository. >> The counterpart is that now maven 2 updates all its plugins with >> SNAPSHOTs >> because in my proxy-all repo, I have metadata updated from snapshots >> repositories. Thus I can't keep these settings without to have a unstable >> environment. >> >> What do you think ? How are you doing ? >> >> Arnaud >> > > -- View this message in context: http://www.nabble.com/Maven-and-Archiva-in-a-corporate-environment-tf3609686.html#a10101750 Sent from the archiva-users mailing list archive at Nabble.com.