Can Gradle handle local dependencies to other than sub-directories?

Question

I don't know if I totally got the concept wrong, but I want to create several projects with dependencies to other projects which are not part of the directory structure of a parent project. I know that the normal way of doing this would be to use an external dependency which fetches from some external repository. But in this case, where let's say in project called 'F' a framework is developed, which is used in project 'P'., then P uses F, but F should IMO not necessarily be a sub-project of P as P is only used to test-drive the development of F (but it's not only a unit test). Later in the process, when F is stable, F is separated and can be consumed by other projects via a repository. But during development of F with P as it's test case, it would be nice if that round-trip through the repository could be omitted.

To make matters worse, for the initial development there is more than one test-driving consumer project, which all need to have a dependency to F, but not via an external repository.

My idea is to develop F in some place on the disk with it's own git reposity. The other P like projects reside somewhere else on the disk and have a local file system based dependency to F. Would such a construct be possible in Gradle? If so, where do I start? I scanned the Java examples but couldn't find an appropriate example.

Any ideas?

Answer 1

You could consider a folder hierarchy like this one:

Main folder
|- F folder
|  |- .git
|  |- sources
|  |- build.gradle (with parts specific to F)
|- P folder
|  |- sources
|  |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle

So you can always decide to run gradle on either the F project, the P project or the two alltoegether. It will also allows you to promote you F project alone without the P or any other side projects.

For more up-to-date information, check Chapter 36 of the Gradle documentation.

Answer 2

The Gradle project hierarchy is fully virtual. It just has the default that the physical location corresponds to the virtual hierarchy. But you have complete control over this. See: http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html#sec:settings_file

Regarding your other ideas have a look at the following Jira: http://jira.codehaus.org/browse/GRADLE-1014