On Feb 4, 2013, at 5:55 AM, Nicolas Delsaux <nicolas.dels...@gmail.com> 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: 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
