I think my case was network issues due to an unstable (enterprise) proxy too. Le 4 févr. 2013 21:22, "Robert Scholte" <[email protected]> a écrit :
> I haven't faced these issues myself, but some colleagues contacted me > about it. > It occurred due to an unstable proxy/network and they knew enough to know > how to switch between the Artifact Repository and connecting to Maven > Central directly. From that moment on they were doomed. > So a good message to explain why the build failed is one. > But more important to me: How should you fix it? IMHO removing the > _maven.repositories is a dirty workaround. If Maven could confirm that an > artifact from repoA is exactly the same as the one from repoB, then the > build shouldn't fail if repoA was unavailable, right? If so, I think this > final step is missing. > > Robert > > Op Mon, 04 Feb 2013 18:03:14 +0100 schreef Jason van Zyl <[email protected]>: > > >> On Feb 4, 2013, at 11:43 AM, Nicolas Delsaux <[email protected]> >> wrote: >> >> On Mon, Feb 4, 2013 at 5:14 PM, Jason van Zyl <[email protected]> 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/<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: >>>>> [email protected].**org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> 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: >>> [email protected].**org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >> 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 >> >> >> >> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
