maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 17:03:14 GMT

On Feb 4, 2013, at 11:43 AM, Nicolas Delsaux <> wrote:

> On Mon, Feb 4, 2013 at 5:14 PM, Jason van Zyl <> 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)
> * (use as
> example artifact com.adobe.flex.framework:flex-framework:
> * (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 ( 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

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:
>>> For additional commands, e-mail:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> ---------------------------------------------------------
>> Selfish deeds are the shortest path to self destruction.
>> -- The Seven Samuari, Akira Kurosawa
> -- 
> Nicolas Delsaux
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message