Hi Jason, Am 03.02.2013 21:40, schrieb Jason van Zyl:
On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <m...@batmat.net> wrote:+1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository 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?
IMHO Yes. Cheers Jörg
smime.p7s
Description: S/MIME Kryptografische Unterschrift
