Hi Luke, we are also accessing the cache directly, because we clone the cache to our own local validated Jar-Repository. The old structure of the cache was perfectly fine for this. Everything worked out of the box with <5 lines of gradle code. Now the simple copy task will become more complicated to remove the hash code.
So I'm very interested in possible alternative ways you could think of! Thanks for your help. Greetings Thomas 2011/8/1 Luke Daley <[email protected]> > > On 01/08/2011, at 12:26 AM, Jeff Brown wrote: > > > In Grails we have some code in our build that copies jar files from > > the Gradle cache to another location (we do have a good reason for > > this but that isn't relevant to my question). In 1.0-milestone-3 we > > look for the artifacts at a location like this: > > > > > /Users/jeff/.gradle/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-1.8.0.jar > > > > In 1.0-milestone-4 they are located at a location like this: > > > > > /Users/jeff/.gradle//caches/artifacts/org.codehaus.groovy/groovy/30ff99c0bcf5520fb6f0e1c2fb71006d/jars/groovy-1.8.0.jar > > > > The cache directory is now caches/artifacts, which is not a problem. > > I am curious about the hash part of the directory structure. Is that > > intentional? > > Yes it is. The hash identifies the repository that the artifact came from. > > What's your reason for accessing the cache directly? Maybe we can find an > alternative way. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
