Why does Gradle need a settings.gradle file?

Question

I am going to convert my Android projects from Ant to Gradle.

My Eclipse workspace is very simple:

Workspace
     MyApp
     MyApp-AndroidLibrary

When I add a build.gradle file in MyApp, I want to reference my Android library project:

apply plugin: 'android'

dependencies {
     compile fileTree(dir: 'libs', include: '*.jar')
     compile project(':MyApp-AndroidLibrary')
}

When I run gradle build, there is an error "Project with path ':MyApp-AndroidLibrary' could not be found in root project", I googled for this, and found I need to setup a "settings.gradle" file in my workspace directory, to add

include ":MyApp"
include ":MyApp-AndroidLibrary"

This looks too bad for me, why Gradle need a settings.gradle file, why not just extract the projects I defined in the dependencies?

And what include really means? What if I have anotoher app and some other shared libraries in workspace, the structure may look like this:

Workspace
     App1
     App2
     Library1(Used by App1 & App2)
     Library2(Used only by App1)
     Library3(Used only by App2)

Because there is only ONE settings.gradle file, I had to add them all into settings.gradle. That does not smell good.

And yes, I can re-organize the strucuture to make Library2 into a child directory of App1, and Library3 to be a child directory of App2, but what about Library1?

Any comment on this?

Answer 1

You are asking several different questions. Here are some hints:

• ':MyApp-AndroidLibrary' is a logical project path, which gets mapped to a physical path based on information provided in settings.gradle.
• A multi-project build can have an arbitrary directory structure, which is configured in settings.gradle. No need to move directories around, unless you want to.
• Eclipse workspace and Gradle build are separate boundaries. You can have multiple builds in the same workspace.
• When working with libraries built from source, you can either make them part of the same build, or have a separate build for them. In the latter case, you need to make sure to build the library before the app, and exchange artifacts via a Maven or Ivy repository. This could be automated using a CI server and a corporate Maven/Ivy repository. Alternatively, you could trigger the library's build manually on your machine and use a local Maven/Ivy repository.

For more information, check out the Gradle User Guide, especially the chapter on multi-project builds.