Hi Jason,
Am 03.02.2013 21:40, schrieb Jason van Zyl:
> On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS <ml@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
|