Nested multimodule builds with a flat directory layout?

I have a nested multiproject built. I.e. settings.gradle in project-a has

includeFlat ‘project-b’ project-b has another settings.gradle

includeFlat ‘project-c’ All projects are in immediate subdirectories of the same parent directory.

Building project-b works without a hitch. Building project-a fails because Gradle can’t find project-c for project-b. The problem persists even if I includeFlat project-c inside project-a as well. (I tried disabling the settings.xml in project-b to exclude the possibility of some misconfiguration in project-a, but then project-b’s model would fail to get constructed.)

I have no idea what could be wrong, except that maybe Gradle somehow mishandles a settings.gradle inside a project that itself was pulled in as a submodule.

This all is happening inside the Eclipe-plugin-provided Gradle, i.e. Gradle 1.2.

Any thoughts?

Currently, ‘settings.gradle’ can’t be nested; you can only have a single one.

Okay… then how do I set up a set of Eclipse projects with the Gradle plugin, with these dependencies: - a1 depends on b depends on c - a2 depends on b depends on c The whole point of having these projects open in Eclipse is, of course, that any changes in c should affect b, a1, and a2 in an as automatic fashion as possible.

Of course I could simply replicate b’s settings.xml to a1 and a2, but then I’d have to delete b’s settings.xml, requiring more explanation for the team that starts working on a3. Plus I’ll have to talk to them every time I merge or split c into more subprojects (something we’re doing pretty frequently). Not that replicating to a1/a2 wouldn’t be a working stopgap solution, it’s just that I feel dirty whenever I use a stopgap solution :wink:

I assume you mean ‘settings.gradle’. The simplest solution is to have a single build with projects ‘a1’, ‘a2’, ‘b’, and ‘c’.

Yep, settings.gradle, sorry for the confusion. (My Maven exposure shows I guess…)

Yeah, single build would be a possibility. Until we’ll have that other team that does project a3 which depends on b and c, then we cannot do single build anymore. Fortunately, that other team won’t materialize anytime soon, but when it does, we’ll have to remember modifying the settings.gradle to do nested multimodules.

Are there any plans for adding nesting support for settings.xml to Gradle?

Are there any plans for adding nesting support for settings.xml to Gradle?

It’s ‘settings.gradle’. :slight_smile:

There are plans, but I can’t say when they will materialize.

Dammit… settings.gradle, settings.gradle, settings.gradle :slight_smile:

Pity about the lack of a timeline. We’ll have to touch the dirt then.

Thanks for the feedback!

Errgh… I can’t build the thing. Removing settings.gradle from project-b and starting a gradle build in project-a gives me: Project with path ‘project-c’ could not be found in project ‘:project-b’.

Is a nested multimodule build possible at all? Should I try dependencies instead?

As I said, a Gradle build can only have a single ‘settings.gradle’. The nesting can be arbitrarily deep, but all projects have to be declared in that single file.

I’m not sure how that answer relates to the question. The issue is that project-b is sandwiched betwen project-a and project-c. I understand that project-b cannot have a settings.gradle,so I put the information in project-a’s settings.gradle; however, when Gradle tries to figure out the build configuration of project-a, it tries to do that for project-b, which is now referencing project-c but doesn’t have project-c in a settings.gradle because it doesn’t have a settings.gradle anymore.

That’s a catch-22 situation: with a settings.gradle in project-b, Gradle will have a nested settings.gradle situation, without it, it can’t figure out that project-c is part of project-b. So my questions are: 1) Is there even any way to get this project-a -> project-b -> project-c configuration to build? 2) If yes, what is it? 3) If no, what are the alternatives?

I’m not sure how that answer relates to the question.

It is trying to answer the question “Is a nested multimodule build possible at all?”.

Is there even any way to get this project-a -> project-b -> project-c configuration to build?

Yes. You configure it all in ‘settings.gradle’, which will typically be located in project A’s project directory (when using a hierarchical directory layout) or in a sibling directory called ‘master’ (when using a flat directory layout). See the multi-project builds chapter in the Gradle User Guide, and the samples in the full Gradle distribution.

Ah. I had missed/forgotten that “master” convention.

Unfortunately, that’s going to conflict as soon as multiple Gradle builds are supposed to live inside the same Eclipse workspace. Unless you do a lot of subdirectory trickery, which I don’t like because I bet some Eclipse plugin won’t grok that.

Dependencies might be a path of less resistance then.

The ‘master’ convention isn’t mandatory. Its only advantage is that it allows you to run a build from a subproject directory, just like when using a hierarchical directory layout. If you put ‘settings.gradle’ into a different directory, command line builds will have have to be run from that directory (but can still execute selected subproject tasks).

Dependencies might be a path of less resistance then.

Not sure what you mean by that.

PS: With the Gradle Eclipse tooling, hierarchical project directory layouts work just fine in Eclipse.

Oh, then there’s never been any issue with ‘master’, since ‘a’ already is the master project in the configuration.


Turns out that Gradle requires ‘’:b’’ in a dependency declaration; I had ‘‘b’’ (without the colon). My best guess why this was so confusing to me is that the ‘‘b’’ got silently ignored, causing error messages far away from where the error actually was. Of course, I might have misinterpreted some diagnostics from Gradle and something entirely different actually happened :slight_smile:


Re hierarchical project directory layout: Gradle tooling showed some glitches (could be related to being the Indigo version). More importantly, I want the individual projects to be reusable across builds, and a hierarchical directory layout would complicate that horribly. I don’t like it very much that I’ll have to tell everybody which auxiliary projects to checkout for a given main project, but, well, maybe that’s supported when I come to that bridge.

Is there any plan for this feature? This would be a wonderful feature.