maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Delsaux <>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 16:43:29 GMT
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

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:
>> 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:

View raw message