On Mon, Sep 9, 2013 at 10:29 AM, John Dix <[email protected]> wrote:
> Still repro's in Maven 3.1. The bug says it is fixed there if I am reading
> it correctly. However, the artifact is stored in Nexus in exactly where we
> want it: 3rdparty. Maven pulls it down, and rather than acknowledge it's
> existence in the local .m2 repository, it continues to try and find it and
> then dies when it cannot locate. Is this the same thing? The bug doesn't
> read like it is. Bear in mind I am mostly new to Maven and still getting
> used to the lingo.
>
I've been working with Maven for years and occasionally get errors like
this.
Go into your local repository under the appropriate directory tree and look
for a file named _maven.repositories. Delete it (I have no idea what it
does; never bothered to figure out what it's for; it is regenerated as
appropriate). I hate resorting to black magic but this often fixes errors
of this type.
The other possibility is that the file itself is one of those insidious ISP
HTML files that get served up in response to bad DNS requests. Some ISPs
(as often found in coffee shops) will, when you attempt to connect to a
private network or some other resource that can't be found, instead of
serving up a 404 as they should will instead serve up a 200 and give you an
HTML page back. To Maven, this looks like a successful request: you asked
for foo.jar, the site said 200, so Maven saves a hunk of HTML into your
local repository and names it foo.jar. This problem can usually be avoided
by going to the ISP in question with a mob armed with torches and
pitchforks and telling them to get their house in order. If that fails,
tell your boss that VPN connectivity is not working, and so consequently
you have no choice but to go {fishing,skiing,clubbing,parasailing} and
you'll be back once connectivity is restored.
Best,
Laird
--
http://about.me/lairdnelson
