On 20/01/2011, at 6:21 AM, Peter Niederwieser wrote:
>
> Frank Wilson wrote:
>>
>> However if I execute Gradle from one of the subprojects it has no
>> knowledge of the tasks that are normally configured by the build.gradle
>> script in BuildCommon. Is there a best practice for doing this backwards
>> reference to BuildCommon?
>>
>
> The user guide has detailed information on this. For projects with flat
> physical layout, the directory of the root project must be named "master".
> Otherwise, running the build from a subproject directory won't work (but you
> can still run a subproject build from the root project directory with
> "gradle :subproject:build"). I'm not very fond of the "master" naming
> convention; maybe we could make this configurable.
>
I don't like it either. Some options for addressing this:
* Deprecate 'master' and use 'gradle' instead. I'd like to end up with all
build related artifacts under $projectDir/gradle. This includes the wrapper
support files (which we've already moved), buildSrc, the root settings.gradle,
checkstyle and codenarc config files, maybe gradle.properties. We might also
make it a default search location for the build script. This way, we end up
with a clean top-level directory.
* Search for any */settings.gradle, and assert that there is exactly one. You'd
use the -c/--settings-file command-line option when there are multiple.
> Frank Wilson wrote:
>>
>> /*
>> * I intend to generate the following includes automatically
>> * depending on what projects have been checked out
>> */
>> include 'ModuleA'
>> include 'ModuleB'
>>
>
> No need for code generation here (if that's what you mean). Instead, you
> could do something like this (I haven't tested this code):
>
> includeIfCheckedOut 'ModuleA'
> includeIfCheckedOut 'ModuleB'
> // list all other modules here
>
> def includeIfCheckedOut(projectName) {
> if (rootProject.file("../$projectName").exists()) include(projectName)
> }
>
> If you need to support the case where checked-out projects depend on
> not-checked-out projects which are, however, available from a repository,
> you will have to do some scripting in build.gradle similar to the above.
This is something we want to tackle for the 1.0 release. It's on the roadmap as
'build aggregation'.
The basic idea is that there's be some way to replace a project dependency with
an external dependency at configuration time, and vice versa. This would be
used to:
* Allow you to specify some subset of projects to build locally, and Gradle
will treat project dependencies on the excluded projects as external
dependencies. It would fetch the artifacts for the excluded projects from a
repository somewhere (possibly a local one).
There might be a bunch of ways for you to define the set of projects to build -
possibly some static groups defined in the build script, or a command-line
option, or some dynamic rule (eg exclude those which are not checked-out).
The use case here is to allow developers to work on a subset of a large build
without requiring them to build or test the whole thing.
* Allow you to combine several builds into a single logical build, and Gradle
will treat external dependencies on projects in other builds as project
dependencies. It would build the artifacts locally instead of fetching them
from a repository.
Again, there might be a few different ways to define the set of builds to
combine.
Both of these would be integrated with the IDE plugins, so that the IDE is set
up to match what Gradle would build locally or fetch from a repository.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
