CODEWITHSUNDEEP
javagradle
BitPusher
BitPusher

Reputation: 1030

Gradle subproject configuration not invoked with configureondemand=true

Here's an analogous project layout of my use case:

gradle
├── parent
│   ├── build.gradle
│   └── child
│       ├── build.gradle
│       └── src
│           └── main
│               └── java
│                   └── Foo.java
└── settings.gradle

With the goal of configuring the 'configureJava' task of the gradle java plugin in the parent such that all children will use the same configuration. To keep things simple, I've removed configuration specific to my use case.

File contents are noted below.

gradle/settings.gradle:

include ':parent:child'

gradle/parent/build.gradle:

subprojects {
    apply plugin: 'java'

    configure([compileJava]) {
        logger.info("******* configuring compileJava! *******")
    }
}

gradle/parent/child/build.gradle:

apply plugin: 'java'

gradle/parent/child/src/main/java/Foo.java:

class Foo{}

Now, if I am to invoke:

gradle compileJava --info

Whether or not my log message is output, as an indicator the subproject configure task kicks in, depends on a particular configuration property: org.gradle.configureondemand.

If org.gradle.configureondemand is set to true, no message. If false, lo and behold; I get my log message.

My next thought is this must be due to my version of gradle. Though the behavior between what I have installed (v1.11) and the latest and greatest (v2.0) are the same.

My question is, as far as configure on demand is concerned; is this expected by design? Or is this a bug? There are a handful of possibly related tickets on the Gradle JIRA instance however I'm not familiar enough with the project to be certain if an existing item might already cover this behavior.

Upvotes: 1

Views: 433

Answers (1)

Peter Niederwieser
Peter Niederwieser

Reputation: 123940

With configure-on-demand, only the current subproject's build script and the root project's build script will get evaluated, plus those of any depended-on projects. However, your settings.gradle sets up a three-level project hierarchy (root-parent-child), which means that parent won't get configured.

Upvotes: 1

Related Questions