Strange (unresolved) library versions -- working@machinename?

I have the following dependencies:

dependencies {



providedCompile “javax.servlet:servlet-api:2.5”







testCompile “junit:junit:4.10”

testCompile (‘org.easymock:easymock:3.0’) {transitive=true}

testRuntime “cglib:cglib-nodep:2.2” // I don’t think I’m supposed to need this…


I cleared out my gradle cache, uncommented mavenCentral() and when I ran the build stuff started downloading ok, but then I got these messages, which don’t seem to make sense. I’m sure they are transitive dependencies of stuff I have declared, but what is up with the ;working@PHECK-L bit (PHECK-L is the name of my laptop).

Could not resolve all dependencies for configuration ‘:compile’:

  • unresolved dependency: antlr#antlr;working@PHECK-L: not found

  • unresolved dependency: commons-collections#commons-collections;working@PHECK-L: not found

  • unresolved dependency: dom4j#dom4j;working@PHECK-L: not found

  • unresolved dependency: org.hibernate#hibernate-commons-annotations;working@PHECK-L: not found

  • unresolved dependency: org.hibernate.javax.persistence#hibernate-jpa-2.0-api;working@PHECK-L: not found

EDIT: I’ve narrowed it down to the hibernate depenency, all others download fine. Is this a known issue with the hibernate pom files?

EDIT 2: Even weirder, this only occurs when I have mavenCentral() uncommented. More background: I had previously had no problem with grabbing hibernate, and have transferred the jars to local flatDir repositories. When I uncomment mavenCentral, it fails to see the flatDir repository (because it’s appending the working@PHECK-L bit, which seems to be Ivy ligo for “we have nfc what the version is”). If I comment out mavenCentral(), it happily sees the existing antlr and other jar files.

This came about because I was trying to add new dependencies. (but note that commenting out hibernate makes it all work even with mavenCentral left uncommented). This is just weird.

You’re right, the “working@[machine]” revision is inserted by ivy when it can’t determine the revision from the artifact path. I suspect this is happening with your flatDir repository, but without more details it’s hard to be sure.

We’d like to track down the exact issue, and you can do a couple of things to help: 1) Try using the Milestone7 release candidate (, or Milestone7 final if it’s released. 2) Try placing the mavenCentral() repository definition before/after the flatDir repository definition, and see if this makes a difference. 3) Run the build with “–debug” and see if it gives some clues about what’s going on.