How to identify if module runs within composite build

(Simon Schmalz) #1


I am currently working with gradle composite build and was wondering how I can tell within a submodule, that I am running in a composite setup?
We have the situation, that the behaviour of one submodule task has to change when it is executed from the composite setup. I could only think of very ugly solutions like setting system properties.

Is there a way to tell if i am running in a composite setup?

Thank you in advance and best regards

(Stefan Oehme) #2

The idea of a composite is that the included builds are isolated from each other and should not know that they are running in a composite. Could you please elaborate on your use case? I’m sure we can come up with a solution.

(Simon Schmalz) #3

Hello Stefan,

thank you for support! In our scenario, the composite setup calls deploLocal tasks for each includedBuild. The folowing task is part of the composite setup (composite/build.gradle):

task deployProjects() {
    System.setProperty('isCompositeBuild', 'true')
    dependsOn gradle.includedBuild("nevismock-module").task(":deployLocal")
    dependsOn gradle.includedBuild("servicemock-module").task(":deployLocal")
    dependsOn gradle.includedBuild("mytv-module").task(":deployLocal")
    dependsOn gradle.includedBuild("samserver-module").task(":deployLocal")

The problem is, that the behaviour of mytv-module:deployLocal has to change if executed from the composite setup. I currently have the ugly workaround with system properties where I change the depending Tasks of deployLocal if it was called from the composite setup:

if(System.getProperty('isCompositeBuild', 'true').equals("true")){
    deployLocal.dependsOn deployLocalDependencies
    deployLocal.dependsOn (deployLocalDependencies + "deployServicemock")

That is why I was wondering if ther is a way to tell if the current call of deployLocal was startet from the composite setup.

(Stefan Oehme) #4

Hey Simon,

can you please elaborate why it has to change?


(Simon Schmalz) #5

Hello Stefan,

that is because the deployment of our application changes depending on the repo you work on. We have a composite repo with a few git submodules in it. The deployLocal task on this repo builds all submodules and copys the compiled apps in a common working directory. Unfortunatly each and every submodule has to be functional by itself. That means if you move down on level into one submodule the deployment has still to work. And that is exacly where the the problem is. It is a requirment from IT, that the deployment of the submodules has a different structure. That is why I have to adjust the deployLocal if I am not running from the composite setup.

Best regards


(Stefan Oehme) #6

Could you define a task in your composite that takes the structure from the individual builds as-is and then restructures it according to your needs? That way you can leave those builds unchanged and get better separation of concerns.

Imagine if you needed another composite with a different structure - you wouldn’t want to adjust each project for that again.

(Simon Schmalz) #7

It is very unlikely, that the structure will ever change again, but I see your point. But is there no way to know if you were called from the composite setup?

(Stefan Oehme) #8

Not that I’m aware of and it would be against the design intent of composite builds as independent units.

@daz @sterling maybe you can add some insight?


When executed as an included build within a composite build, project.gradle.parent != null

(Simon Schmalz) #10

Hello Daz,

that solved my problem! Thank you very much :slight_smile:

Best regards