Aggregating two Gradle projects into one project

(Etienne Studer) #1


I have two separate Gradle projects that both have their own builds and that can be run self-contained. Often times, I would like to treat these two projects as one project, for example in the IDE or when doing a ‘gradle build’.

What do I have to do to have a project that ‘aggregates’ two Gradle projects? Can I define a master Gradle project that includes two other Gradle projects? If so, how would that look like?

Regards, Etienne

(Peter Niederwieser) #2

Sounds like you just need to write a ‘settings.gradle’ to create a regular multi-project build. Probably you want to keep this in a directory other than the existing project directories.

(Stephane Galles) #3

@Etienne. Actually I have the exact same problem for the aggregation of multi project builds, but as Gradle does not manage (yet) the multi-multi-projects, I emulate this with some kind of snapshot build.

(Peter Niederwieser) #4

If you need to aggregate several multi-project builds, a solution that should work today is to replicate the settings.gradle information of the constituent builds in the settings.gradle of the agreggating build. In other words, the aggregating build pretends that it’s all just one huge build.

Aggregate and partial builds will be a major focus of Gradle 1.2 and beyond.

(Stephane Galles) #5

Thank you Peter, I’m really glad to hear that new features related to these issues are planned.

I understand that one could aggregate two simple builds with a settings.gradle (granted, I guess, that in each build we add something to detect the ‘multi-build’ state in order to switch from ‘library dependencies’ to ‘project dependency’, Etienne may have to do something like that)

For multi-builds I’m not sure how this could work though. If I add a new settings.gradle, I guess I’m creating a new master that encompass all aggregated build. But each original multi-build also had a master. Won’t the original master builds be skipped and replaced by the aggregating master ?

(Peter Niederwieser) #6

You can either place the new settings file in a separate directory and run all builds from there, or pass the new settings file with ‘-c’. (And as I said, the new settings file has to include all projects, not just the root projects of the constituent builds.)