connection-refused: bad? or not…

Elb-Terassen Dresden (Saxony), by Christoph Burmeister (own photo)

Elb-Terassen Dresden (Saxony), by Christoph Burmeister (own photo)

One of our developers needed a jar to be provided via artifactory… happens sometimes. To be exactly, it was eclipselink (something with jpa-persistence). So I browsed all the public repos I knew,  but didn’t find anything except big trouble with the distrib-mgmt of eclipse foundation and many many 404s while trying to access the repo, listed at eclipse-website: . Artifactory shows up a „Connection refused“ message when trying to add this as remote-repository (also nice the total ignorance of other repo-managers at eclipse-website). But thanks to Shawn Chin and HDave via Stackoverflow, here comes the solution: Ignore the Error-Message and just cross your fingers to get the desirered lib via  „“ by


Cite from stackoverflow:


A quick search reveals a long list of mirrors, most of them returning 404s but their cache entry is still viewable (for now). So it does seem like the files have been removed at the source, and rather recently too.


This thread on the eclipselink mailing list reveals something rather bizzare — while the maven.repo directory is not accessible (404), subpaths that resolves to .jar or .pom files will still work!

  • This currently fails:
  • But this works:

While the relevant files are still accessible, this messes up the mirroring process as well as any workflow that first checks if the repo exists. From the linked thread:

„This of course wreaks havoc on any Nexus or Artifactory repository you may have that proxies the EclipseLink repository, as it will conclude that EclipseLink’s repo is out of service even though strictly speaking it is not. The solution is to turn off any automatic checking of the repository and/or automated blocking of it.“


By the way, after downloading the first artifact from this brand-new-remote-repository, our Artifactory shows up „Successfully connected to server“.