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 16:14:38 GMT

On Feb 4, 2013, at 5:55 AM, Nicolas Delsaux <> wrote:

> Sorry to jump in that conversation like the user I'm, but having seen
> some messages of both Arnaud and Olivier, I feel I should add my own
> noise to that discussion.
> First, a little context info.
> My company build a complex system, involving flexmojos artifacts and
> other ones coming from various repositories (maven central, obviously,
> but also jboss one and now defunct Tinkerpop one).
> Due to budget restrictions, we couldn't yet install an enterprise proxy.
> As a consequence, our build directly check artifacts from these remote
> locations.
> Unfortunatly, Tinkerpop recently decided their artifacts could now be
> hosted on maven central.
> What do you think happened to our build ?
> Yup. Failure all the way long.
> And what do you think happen when the repository hosting the various
> flexmojos artifacts goes down ? Yes, failure also. Failure because of
> this artifact identification mechanism.

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.

I'd be interested in looking at your configuration as this safeguard only results in failure
when an artifacts are not available remotely.

Though this is not strictly a repository manager problem. It is a problem when the configuration
changes result in pointing Maven at a different set of remote repositories. Where artifacts
available via one configuration are not available to another. You can think of Maven behaving
as if it were always building from an empty local repository. If this condition cannot be
met Maven will fail: Maven does not care what you have locally, it cares that in the context
of the current configuration you can resolve a particular artifact.

> I perfectly understand Jason for a better artifact identification
> mechanism than the GAV one. BUT, I also consider the current solution
> to be more a pain than a feature as it is uninformative (I'm sorry if
> this message may feel aggressive, because it is not my goal).
> To my mind, Jason solution of also storing an artifact MD5 or any
> identification mechanism would be a far better solution than
> hard-storing the repository from which an artifact was received.

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?

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



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

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

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