On Mon, Feb 4, 2013 at 5:14 PM, Jason van Zyl <ja...@tesla.io> wrote: > > > If you have no proxy and you are all just pointing at Maven Central then this > particular feature will not affect you. Maven, with no mirrorOf configuration > in a settings.xml, will follow the repositories listed in the POMs. If you > several settings.xml files and switch between them you may potentially have > issues.
Well ... it appear that, most of the time, I've got issue not by switching my settings.xml, but rather with a remote repository (not maven central) being down. > > I'd be interested in looking at your configuration as this safeguard only > results in failure when an artifacts are not available remotely. I'm using as remote repositories (the ones with troubles) * http://repository.sonatype.org/content/groups/flexgroup/ (use as example artifact com.adobe.flex.framework:flex-framework:3.4.0.14408) * http://tinkerpop.com/maven2 (use as example artifact com.tinkerpop.blueprints:blueprints-core:1.1) Both these repositories may sometimes be down, in which case my build fail, ignoring my locally downloaded artifacts. What I find personnally annoying is the fact that maven successfully downloaded these artifacts before, so why not use locally cached ones ? > > I have an implementation that does stronger identification checking. But this > kicks in after Maven has determined there is something by that GAV available > remotely and is not something you'll be affected by because it's not a > publicly available feature. > Again, the description for this particular > feature: > > --- > > The feature verifies that the remote repositories configured for the current > build can be used to successfully resolve the artifact in question. If you > retrieved an artifact in the past from Central and now changed your build to > only know about Nexus and it doesn't have any knowledge of that artifact then > the build is going to fail. Put differently, if you purged your local repo, > your build won't work either. Neglecting offline mode, the goal is to ensure > that the resolution works if it could be performed using a clean local repo > with the current configuration. Giving confidence that co-workers can > reproduce the build and not depend on some artifact magically being pulled > down into your local repository in the past which is nowhere to be found in > the configured remote repository. > > --- > > Make sense? > In a sense. But if so, why keeping a local repository ? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > Selfish deeds are the shortest path to self destruction. > > -- The Seven Samuari, Akira Kurosawa > > > > > -- Nicolas Delsaux --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
