baerrach wrote:
>
>> So are there workarounds?
>
Sorry if I'm coming late into this and missed some of the finer points but
we are currently using maven proxy (with an eye to Archiva or Proximity when
they are finally manage a production quality release) to provide us with
some control over the repo access order and to prevent our maven projects
from having to be littered with lots of differing pom.xml defined repo
declarations. Using the proxy as intermediary has the added benefit of
allowing us to obscure artifacts present in one repository with those in
others. Maven itself is only every talking to 2 repos, our RELEASE proxy and
our SNAPSHOT proxy. the RELEASE proxy repo order looks something like this:
inhouse.corporate.release
inhouse.central-ovveride.release
external.central.release
external.codehaus.release
...
Where inhouse.central-override.release does what it says on the tin, namely
verrides artifacts defined in central with our own custom built versions.
Would this not work for most corporate instances?
When Nikunj posted their problem, I was unable to reproduce it because
like you we are using mvnproxy.
If you turn mvnproxy off then there is no way besides the workarounds
I have listed to resolve the problem.
If you are using mvnproxy, the problem is hidden because mvnproxy
aggregates all the defined repositories. So even though maven is
overriding the artifact's repository to central mvnproxy will return
the artifact from your company's repo.
So you could also use mvnproxy to workaround this problem. But if you
are not already using mvnproxy I wouldn't recommend starting to use
it. It's not difficult but the repo aggregation can bring with it
other problems, e.g. dont include snapshot repos in mvproxy or else
they will also get aggregated.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
