On 28/07/2011, at 11:08 PM, Hani Suleiman wrote:

> Is there a strong reason for the hugely obscure artifact directory structure 
> now?
> 
> For projects that manually maintain dependencies without using the gradle 
> idea/eclipse project generation, the files are in very awkward locations and 
> it's no longer clear if this is portable across builds...
> 
> For example:
> 
> .gradle/caches/artifacts/joda-time/joda-time/9ff98ba95d351e8f43772ad9aa9eceeb/jars
> 
> What's the 9f string for? Will it be the exact same string for anyone else 
> checking the project on another machine?

That string is the repository id. Artifacts are now cached on a per-repository 
basis. I'm pretty sure the id is portable: if you have the same repository 
definition, you'll get the same id.

At the moment, we consider the layout of the artifact cache to be an internal 
interface, and it may change at any time. We discourage people from referring 
directly to the cache contents. However, there are certainly use cases for 
getting hold of the cached artifacts, so we want to have solutions for those 
use cases.

I'm curious why you want to maintain your dependencies manually? There might be 
something we can change with the IDE plugins to solve the problem and so let 
Gradle take care of the dependencies for you.

For example, perhaps adding support of the .idea directory format would solve 
your problem. Or the upcoming Idea integration, which will let you import a 
Gradle build as an Idea project.

Another option might be to offer some capability to keep a replica of the cache 
in a friendlier format. For example, perhaps when Gradle resolves a 
configuration, it also creates a copy of the dependencies in 
$projectDir/.gradle/dependencies/$configName (perhaps using symlinks into the 
cache, or perhaps as copies). Then, you can just point the IDE at 
$projectDir/.gradle/dependencies/testRuntime (say).

Or, building on this: the artifacts under $userDir/caches/artifacts are all 
just links into $userDir/caches/artifacts/filestore. We could perhaps get rid 
of these artifact links under $userDir, and just use the above links under 
$projectDir instead. This way, the artifacts are arranged according to purpose, 
rather than origin, and this removes the need for the repo id, and make the 
artifacts much easier to find from other tools, not just those that Gradle is 
aware of.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to