Not being familiar with all of the repositories or dependencies of fedora, it may be worth the cost of fedora/duraspace running a proxy which aggregates and hosts these artifacts.
On Dec 11, 2009, at 12:48 PM, Andrew Woods wrote: > 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 ------------------------------------------------------------------------------ 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
