Gradle 1.0-milestone-4 local cache structure changed cause the Arquillian test broken

Why do you need to use these files directly out of the cache? There might be another approach which can isolate you from the cache layout.

In Arquillian TestCase, I need to build the test case "war" file and deploy on the server, then it will run in-container test, so it looks like:

@Deployment
   public static WebArchive createDeployment() {
      return ShrinkWrap.create(WebArchive.class).addLibrary(GradleResolver.getArtifact("org.jboss.seam:jboss-el:2.0.0.GA").addClasses(Expressions.class, ExpressionsTestCase.class).addWebInf("web.xml");
   }

and the GradleResolver.getArtifact convert from the string to java.io.File. the best place to get the jar should be from the cache.

I think I found the work around after dug in the gradle source, so in the test task I'm doing this:
configurations.cacheImplProvided.resolvedConfiguration.resolvedArtifacts.each { systemProperties[it.resolvedDependency.moduleGroup + ":"+it.resolvedDependency.moduleName+":"+it.resolvedDependency.moduleVersion]=it.file.path;}

and configurations.cacheImplProvided=[group: 'org.infinispan', name: 'infinispan-core', version: '4.2.1.FINAL']

then in my test case, I can use new File(System.getProperties("org.infinispan:infinispan-core:4.2.1.FINAL")) to get the actual jar file.
Hope this API can be simplified in the future release.

Hey Wang!

I'd like to second to what Adam said earlier. It would be probably better not to depend on the gradle cache format. The format is an implementation detail of Gradle - it is not a public API. On the other hand I'm wondering if the ToolingApi shouldn't have some method to access cached libs?

I think it's important that Gradle provide some kind interface to access the dependent jars in the building process, this is useful and some tools may need that (for Arquillian, it does use the jar File to build the war/ear when testcase runs). It doesn't make sense that I have to have copy the dependent jars in separated place (if I had that I don't need Dependency management and plain Ant works for me in that case).

One of the reason we ditch Maven and come here is that Gradle not force us to do something doesn't make sence to our project and provide some simple way to build. I hope it still does.

The Grails team are also having problems with this as we have a distribution whereby we ship all dependencies inside the Grails zip so people can use Grails whilst offline:

https://github.com/grails/grails-core/blob/master/gradle/assemble.gradle#L3

This currently works by copying the Gradle cache into GRAILS_HOME/lib for all declared dependencies. This is currently broken with 1.0 milestone 4

Is there a supported way to do what we need to do?

Hi guys
A lot has changed in caching and dependency resolution since Milestone 4. We still consider the cache structure to be 'internal' and not part of the public API of Gradle. That said, we'd like to hear about your genuine use cases that require direct access to the cache. I'd like to create new issues for these use cases, and close this issue.

Wang: We do have a DSL for accessing the cached artifact (ResolvedConfiguration). It seems like your issue is that this isn't available from inside your tests? What sort of API are you looking for?

Matt: I assume you're not still stuck on Milestone 3? A lot has changed since then, and Milestone 8 has a '--offline' flag that will hopefully remove the need for you to spin your own.

Graeme: I know that Luke Daley has been working on the Grails build, and will be updating it to use Milestone 8 soon. I assume this isn't a blocker for you.

All: One of our plans is to make available a 'project-specific' view of the cache, perhaps under the PROJECT_ROOT/.gradle directory. This would present the dependencies for a project in a standard directory layout, and would be considered part of the public API for Gradle. I feel this would solve the problems eluded to by Wang and Graeme, but not Matt's, which is solved by the new --offline switch.

Comments?

I've now added GRADLE-2094, and I'd like to close this issue if you guys are in agreement.

I found a way to work around this, put the artifacts ID:filename map into system Properties, and in the test case, read from the system properties:

configurations.default.resolvedConfiguration.resolvedArtifacts.each {ModuleVersionIdentifier module=it.moduleVersion.id; systemProperties[module.group+":"+module.name+":"+module.version]=it.file;}

I guess that's the only way to do it now. this ticket can be closed.