On Feb 4, 2013, at 11:43 AM, Nicolas Delsaux <nicolas.dels...@gmail.com> wrote:
> 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 > ? The underlying assumption is that if they just randomly go away, that it may be permanent and that it won't work for anyone else and considered a failure. The aggregate downtime for RSO (repository.sonatype.org) is very little so that one surprises me. I don't know anything about the older Tinkerpop artifacts but they would probably put the older stuff in Central if we asked. So this is not normal that remote repositories are failing so often that this appears frequently in your builds. But the result internally would be that if it were a developer that were starting from scratch it would fail for them. While repository managers like Nexus OSS are free, I realize it takes time and energy to install one it is a valuable investment. Anyone being onboarded in an environment where connections to repositories are unstable are going to encounter failures even if you disabled this feature. But agreed, in unstable network conditions without a repository manager you're going to have issues. How frequently does this happen? > >> >> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- We all have problems. How we deal with them is a measure of our worth. -- Unknown
