Using settings.gradle in master directory

Old Forum Archive
1

From the user docs, it appears that you can put the settings.gradle file for a multiproject into a “master” directory instead of the top directory. But when I try this, I get an error that appears to indicate that gradle can’t find the settings.gradle file.

Cause: Project with path ‘:A’ could not be found in root project ‘B’.

Here the directory structure is

rootDir

build.gradle

master

settings.gradle

A

build.gradle

…

B

build.gradle

…

and I am running ‘gradle clean’ from within B and B has a compile dependency on A, compile project(’:A’)

I have tried several variations on

include ‘A’, ‘B’ include ‘:A’, :B’ includeFlat ‘…/A’, ‘…/B’ includeFlat ‘A’, ‘B’ but none seem to work.

It is also unclear from the docs if the root level build.gradle can also live with the master directory. What about buildSrc?

I think it would be very nice if all 3 of these (settings.gradle, build.gradle, buildSrc) could live in the master directory. It would make version control much better when each subproject is in a separate mercurial repository, for example, and so having the root directory in version control is weird. Having these off in master makes it easy to version control just the master directory to capture build and settings files without having subprojects inside as well.

thanks, Philip

gradle --version

------------------------------------------------------------ Gradle 1.0-milestone-6 ------------------------------------------------------------

Gradle build time: Thursday, November 17, 2011 5:54:12 AM UTC Groovy: 1.8.4 Ant: Apache Ant™ version 1.8.2 compiled on December 20 2010 Ivy: 2.2.0 JVM: 1.6.0_20 (Sun Microsystems Inc. 16.3-b01) OS: Linux 2.6.18-92.1.13.el5 amd64

2

You can use any directory layout, but if you want to be able to cd into a subproject and run the build from there, then settings.gradle must either be in a parent directory or a sibling directory called master. The root project’s build.gradle will by default be searched for in the same directory as settings.gradle, but you can reconfigure that. If you use a flat directory layout (like the one with master), then includeFlat ‘A’, ‘B’ is the easiest way to declare subprojects. buildSrc is a different build, and I believe its location is currently fixed. In the longer term we will be moving towards a more general solution with explicit support for builds spanning multiple source repositories.

3

OK, so having the settings.gradle in the “master” directory only works the same as having it in the root if you also change “include” to “includeFlat”. It seems like the intent of the master directory is to be the same functionality as if it were in the root directory, and so gradle would recognize the settings in master refers to the root directory?

However, I am still unable to get gradle to recognize buildSrc when using the master directory. Regardless of whether it is in the root or in the master directory it fails. Are buildSrc and master incompatible?

Here is an example using the “samples/customBuildLanguage” sample.

mkdir master

mv settings.gradle build.gradle master/.

cd basicEdition

gradle clean

FAILURE: Build failed with an exception.

  • Where:

Build file ‘/seis/local/noArch/versions/gradle-1.0-milestone-6/samples/customBuildLanguage/basicEdition/build.gradle’ line: 1

  • What went wrong:

A problem occurred evaluating root project ‘basicEdition’.

Cause: Plugin with id ‘product’ not found.

  • Try:

Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 1.589 secs

Then trying buildSrc inside master also fails.

mv …/buildSrc/ …/master

gradle clean

:buildSrc:compileJava UP-TO-DATE

:buildSrc:compileGroovy UP-TO-DATE

:buildSrc:processResources

:buildSrc:classes

:buildSrc:jar

:buildSrc:assemble

:buildSrc:compileTestJava UP-TO-DATE

:buildSrc:compileTestGroovy UP-TO-DATE

:buildSrc:processTestResources UP-TO-DATE

:buildSrc:testClasses UP-TO-DATE

:buildSrc:test

:buildSrc:check

:buildSrc:build

FAILURE: Build failed with an exception.

  • Where:

Build file ‘/seis/local/noArch/versions/gradle-1.0-milestone-6/samples/customBuildLanguage/basicEdition/build.gradle’ line: 1

  • What went wrong:

A problem occurred evaluating root project ‘basicEdition’.

Cause: Plugin with id ‘product’ not found.

  • Try:

Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 5.199 secs

4

OK, so having the settings.gradle in the “master” directory only works the same as having it in the root if you also change “include” to “includeFlat”.

Works as designed. include/includeFlat is relative to settings.gradle.

It seems like the intent of the master directory is to be the same functionality as if it were in the root directory, and so gradle would recognize the settings in master refers to the root directory?

The directory containing setting.gradle in a flat layout doesn’t have to be named master, and the directory containing settings.gradle in a hierarchical layout could be named master. So it wouldn’t be good to have different semantics for include depending on whether the directory is named master or not.

5

However, I am still unable to get gradle to recognize buildSrc when using the master directory. Regardless of whether it is in the root or in the master directory it fails. Are buildSrc and master incompatible?

I just tried a similar example and it worked just fine. buildSrc needs to go into the root project directory. The latter defaults to the directory containing settings.gradle (master in your case).