maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Hohwiller <>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Sun, 10 Feb 2013 23:01:17 GMT
Hi Jason,

Am 03.02.2013 21:40, schrieb Jason van Zyl:
> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <> wrote:
>> +1.
>> Though the feature seems interesting, it should have had its own
>> advertisement while being introduced.
>> Even after re-reading
>> I'm
>> still unsure about where/when it would bite me.
> Does this make sense to you?
> ---
> h1. Enhanced Remote Repository Support
> 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.

I see your point but there is a missmatch between theory and reality.
1. Because mirrors of my company have been blacklisted we "forced" every 
employee to use a enterprise maven repo (via <mirrorOf>*</mirrorOf>). 
Swtiching to private projects causes offline builds to fail.

2. Providing internal arftifacts via USB-Stick to collegues that do not 
yet have access to the projects enterpise repo is now not possible 
without deleting _maven.repositories what is causing massive confusion 
and a waste of time and energy. People get really angry about maven and 
want to switch to gradle or builder. I am a fan of maven but I can not 
argue for this "feature".

3. But it gets even worse: Even though OSSRH is performing validation 
there are still new artifacts getting into central that are somehow 
invalid (have a groupid that is not compatible to the path in the 
repository). Downloading directly from central works anyways but NOT via 
artifactory that we are using because of the blacklisting. Now some 
developers did not use mirrorOf but added artifactory as additional repo 
and used an other proxy with an IP that is not blacklisted. They had no 
problems but others that followed the official policy failed to build 
because even if they had the artifact in local repo it could NOT be 
downloaded again via artficatory.

> ---
> And would you want that off by default?



View raw message