Is there any alternative to using settings.gradle for multi project builds?

Old Forum Archive
1

Needing to have a gradle.settings file for multi-project builds is ugly IMO. I’d like to be able to specify the sub-projects in the main build.gradle. The docs suggest that settings.include() can do this but I can’t get it to work. Any suggestions?

2

At the moment the only way to define multi project builds is a settings.gradle file. The settings.include does not work in a build.gradle file. There was a discussion going on some time ago about skipping this settings.file at the gradle mailing list. I am not aware of the current plans for the settings.gradle file.

regards, René

3

Looks like there’s an issue open for this. I’ve voted for it. http://issues.gradle.org/browse/GRADLE-338

4

OK - I believe I’ve got it:

task release(type: GradleBuild) {
    tasks = ['build']
}
5

I am also looking into this. The settings file is a problem.

6

I am also looking into this. The settings file is a problem.

Why is it a problem?

7

There is a higher level of maintainability if there is only one file. This is more like a dependency so I think they should be to put them in one place.

1 Like
8

My suggestion is that there are 3 way to handle this 1) apply from project ‘…’ 2) include ‘…’ - like in settings 3) dependencies { project(’…’) }

9
  • It’s unnecessary * It’s confusing * It’s cumbersome
10

Well said.

11

Hi Jordan,

Please give specifics of how it is unnecessary, confusing and cumbersome and we’ll do our best to incorporate your suggestions.

12

It’s unnecessary because it would be feasible to add it to the main file. It’s confusing because other systems don’t use multiple build files. It’s cumbersome because having to manage multiple files is much more difficult than managing one file.

13

I agree with you totally!

14

I certainly agree that one file would be simpler to manage, but it is very difficult to implement (there are classpath, performance and ordering problems). We do have some plans to unify this at some point with some compile time trickery, but it’s not high priority. This isn’t intended to provide new functionality, just remove the extra file if possible.

However, at the moment there is no alternative to using the ‘settings.gradle’ file.

15
but it is very difficult to implement
I'm curious why it's difficult? I can imagine a simple implementation that does two passes. Pass one looks for build file meta commands such as "settings", etc. Of course, it's easy to play armchair coder.
16

One issue is that every *.gradle file in the current directory and above would have to be searched for the “settings” block which would be very costly.

Another is that “looking” for the settings block is complicated, because we couldn’t just execute the scripts as certain build script functions can’t be performed until the whole build structure is mapped. Also, this would in itself have a performance penalty compared to a special purpose file.