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

(Jordan Zimmerman) #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?

(René Groeschke) #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é

(Jordan Zimmerman) #3

Looks like there’s an issue open for this. I’ve voted for it.

(Jordan Zimmerman) #4

OK - I believe I’ve got it:

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

(sirinath1978m) #5

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

(Peter Niederwieser) #6

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

Why is it a problem?

(sirinath1978m) #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.

(sirinath1978m) #8

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

(Jordan Zimmerman) #9
  • It’s unnecessary * It’s confusing * It’s cumbersome

(sirinath1978m) #10

Well said.

(Luke Daley) #11

Hi Jordan,

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

(Jordan Zimmerman) #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.

(sirinath1978m) #13

I agree with you totally!

(Luke Daley) #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.

(Jordan Zimmerman) #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.

(Luke Daley) #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.

Subprojects and multiple settings.gradle scripts