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 <ja...@tesla.io>:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
