Thanks, Chris. DuraCloud also has dependencies through maven-repository.dev.java.net and has intermittently suffered from its flakiness. Although the repository has thus far always come back online, it would save us all a headache if we avoided it altogether. Andrew
On Fri, Dec 11, 2009 at 7:17 AM, Chris Wilper <[email protected]> wrote: > I've been struggling with this for a few hours now, and wanted to > report where it's at, since I'm traveling and in meetings today...so > I'm not sure how much time I'll have to resolve it today. > > The build is failing due to a defunct maven repository: > maven-repository.dev.java.net > > Although none of our poms point to this, at least one of our > dependencies does. This causes maven to try to use it for downloading > dependencies. And because of the way this repository behaves (sending > a redirect, which results in a 404 on another server), this causes the > content of the 404 page to be written in the local ~/.m2 repository as > the content of the jar/pom that is being downloaded. And then the > build fails later down the line because the pom and/or jar is invalid. > > There's a related issue here: http://jira.codehaus.org/browse/MEV-649 > > The first thing I tried was to blow away the bad dependencies from the > local repo, then change our pom to start using log4j 1.2.14. This > didn't work, so I assume another one of our dependencies (possibly > transitive, and probably in fcrepo-security) is pointing to this bad > repository as well. > > So I backed out that change and instead added central explicitly in > our root pom, as the first repository (naively thinking that might > tell maven to try to load dependencies from that repository first). > It didn't. > > My next move was rather brute force, but I modified /etc/hosts to > point to a bogus IP address for the bad repository's hostname...just > to see if it would work. It did. And I suspect this will work for > others as a workaround for now, till the problem gets solved in a > better way. > > I think the right way to solve it is probably to track down the full > set of fcrepo dependencies that point to this repository and see if we > can avoid them. That, or find out which id each of those poms uses > for the defunct repository and disable them as explained in MEV-649. > But maybe not via settings.xml -- I think it could also be done in our > root pom. I think that would be better, because it wouldn't require > people downloading the source to take any special steps in order to be > able to build it. > > - Chris > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
