Taking advantage of configuration on demand?

For the time being (when you try out 2 different gradle versions), you need those 2:

systemProp.org.gradle.configuration.ondemand=true org.gradle.configureondemand=true

When 1.5 is released, you’ll keep only the latter.

Hope that helps!

I think I’m hitting a bug.

If I run my tasks from the master directory (i.e. gradle-1.6n :projA:hi), then Gradle picks up the property and runs in configuration on demand mode:

master$ gradle-1.6n :projA:hi
Configuration on demand is an incubating feature. Enjoy it and let us know how it works for you.
Configuring projA
:projA:hi
projA says hi
  BUILD SUCCESSFUL

If I switch to another directory (say, projA) and run a task, Gradle doesn’t pick up the property and runs normally:

projA$ gradle-1.6n :projA:hi
Configuring projA
Configuring projB
:projA:hi
projA says hi
  BUILD SUCCESSFUL

This is something more general. This has to do with how Gradle finds the master dir.

This is a limitation of the ‘master’ dir pattern. You have to launch Gradle in the directory that contains the ‘master’ dir. What surprises me though is that Gradle detected it’s a multi project build at all. What’s the layout of your project?

What? I’ve been using Gradle since 1.0M3, and I’ve always used the flat directory structure with my build files in master, and I’ve always been able to run tasks from any subproject’s directory.

According to section 50.4 (Build Lifecycle: Initialization) (http://www.gradle.org/docs/current/userguide/build_lifecycle.html#sec:initialization):

If you execute Gradle from within a project that has no settings.gradle file, Gradle does the following:
  * It searches for a settings.gradle in a directory called master which has the same nesting level as the current dir.
...

According to the Settings DSL for the includeFlat method (http://www.gradle.org/docs/current/dsl/org.gradle.api.initialization.Settings.html#org.gradle.api.initialization.Settings:includeFlat(java.lang.String[])):

void includeFlat(String[] projectNames)
  Adds the given projects to the build. Each name in the supplied list is treated as the name of a project to add to the build.
  The supplied name is converted to a project directory relative to the parent directory of the root project directory.
  As an example, the name a add a project with path :a, name a and project directory $rootDir/../a.

This is exactly the setup I have:

/
|- master
|
|- settings.gradle
|
|- build.gradle
|
|- gradle.properties
|- projA
|- projB

As you can see from my earlier commens, when I put code into build.gradle or settings.gradle, the properties are being read, no matter which directory I execute from. But, when I run from a subproject, they’re getting loaded too late in the process to activate configuration on demand.

You’re right. I actually didn’t know that about include flat.

So you’re sure that the gradle.properties file is read, but it’s somehow non effectual (possibly because it’s read too late)?

Yes, that’s correct.

Running from master:

master$ gradle-1.6n :projA:hi
In settings
Configuration on demand is an incubating feature. Enjoy it and let us know how it works for you.
In master/build.gradle
build.gradle rootProject property: org.gradle.configureondemand: true
Configuring projA
:projA:hi
projA says hi
  BUILD SUCCESSFUL

Running from projA:

/projA$ gradle-1.6n :projA:hi
In settings
In master/build.gradle
build.gradle rootProject property: org.gradle.configureondemand: true
Configuring projA
Configuring projB
:projA:hi
projA says hi
  BUILD SUCCESSFUL

The debug output is particularly interesting, since output from both directories shows loading the properties files.

From master:

[INFO] [org.gradle.BuildLogger] Settings evaluated using settings file '{SNIP}/GradleCOD/master/settings.gradle'.
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/master/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Adding project properties (if not overwritten by user properties): [org.gradle.configureondemand]
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/projA/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Adding project properties (if not overwritten by user properties): [org.gradle.configuration.ondemand, systemProp.org.gradle.configureondemand, systemProp.org.gradle.configuration.ondemand, org.gradle.configureondemand]
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/projB/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] project property file does not exists. We continue!
[INFO] [org.gradle.BuildLogger] Projects loaded. Root project using build file '{SNIP}/GradleCOD/master/build.gradle'.
[INFO] [org.gradle.BuildLogger] Included projects: [root project 'master', project ':projA', project ':projB']
[LIFECYCLE] [org.gradle.util.DeprecationLogger] Configuration on demand is an incubating feature. Enjoy it and let us know how it works for you.
[INFO] [org.gradle.configuration.BuildScriptProcessor] Evaluating root project 'master' using build file '{SNIP}/GradleCOD/master/build.gradle'.

From projA:

[INFO] [org.gradle.BuildLogger] Settings evaluated using settings file '{SNIP}/GradleCOD/master/settings.gradle'.
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/master/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Adding project properties (if not overwritten by user properties): [org.gradle.configureondemand]
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/projA/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Adding project properties (if not overwritten by user properties): [org.gradle.configuration.ondemand, systemProp.org.gradle.configureondemand, systemProp.org.gradle.configuration.ondemand, org.gradle.configureondemand]
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Looking for project properties from: {SNIP}/GradleCOD/projB/gradle.properties
[DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] project property file does not exists. We continue!
[INFO] [org.gradle.BuildLogger] Projects loaded. Root project using build file '{SNIP}/GradleCOD/master/build.gradle'.
[INFO] [org.gradle.BuildLogger] Included projects: [root project 'master', project ':projA', project ':projB']
[INFO] [org.gradle.configuration.BuildScriptProcessor] Evaluating root project 'master' using build file '{SNIP}/GradleCOD/master/build.gradle'.

They both show Gradle loading properties from master, projA, and projB. But, in the projA run, that LIFECYCLE event between “Included projects” and “Evaluating root project” is missing.

Just in case, I tried copying master/gradle.properties into projA/gradle.properties. It didn’t change anything. However, copying it to ~/.gradle/gradle.properties does activate configuration on demand.

many thanks for the detailed info. Will help greatly in narrowing the issue down.

I’ve updated my sample repository (https://github.com/Nazrax/gradle-configuration-on-demand-sample) to 9150b25.

Adrian, can you tell me how do you work with this sample project? When I run ‘gradle projects’ from the root dir of this project it does not show me any subprojects, also the master is not configured. Cheers!

I’m getting the feeling that the flat layout doesn’t get a lot of love …

“master” is the root project. Run “gradle projects” from there.