Settings.include 'project-A' triggers the compilation even though project-A is not kept as dependency for the current project

Help/Discuss
1

I have included many projects in settings.gradle file, out of which nothing is avaialble in build.gradle’s dependencies{} block.

The compilation is done for the included projects and compilation error comes even though is is not available in dependencies block.

Should I include only the required projects in settings.gradle? Will extra projects be subjected to compilation?

Is it the behavior? Pls clarify

2

Since you are including other projects in a settings.gradle file, you have a multi-project. In a multi-project, there can only be one settings.gradle file, so no, you should not create additional ones.

When you say “the compilation is done for the included projects” even though they are not referenced in the dependencies block, I assume you are running gradle build from the root project on the command line.

In this case, Gradle will execute the build task not only in the current project, but also in all sub-projects, no matter if you have declared dependencies to them from the root project or not. This is by design and allows you to easily build all projects without having to wire individual tasks together. The same happens if you type gradle clean – not only will it clean the root project but also all sub-projects.

If you like to only build a single project from the command line, you can prefix use the fully qualified task name, which for the most part is the path to the project, where slashes are replaced with colons. For instance, gradle :build will only execute the build task in the root project (and anything you have declared dependencies to in the dependencies block). You can also from the root project build a single sub-project through something like gradle :subProject:build, or you can just change to that folder and build from there.

So this means you can have as many projects included in the settings.gradle file as you like. It is up to you if you want to build them all in one go, or only some of them.

You can read more about multi-projects and how to work with them in the user guide under Executing Multi-Project Builds.

3

Ok. Clarified. Thanks for your reply.
Below is the problem I am trying to resolve.

In our company we have many project hierarchies

Client:1

project-d (rootProject)
|___project-c
       |___project-b
              |___project-a

Client:2

project-e (rootProject)
|___project-b
       |___project-a

Client:3

project-f (rootProject)
|___project-g
|___project-b
       |___project-a

There are many such hierarchies …

i.e., same core modules will be part of many client projects. But, the rootProject for each client project is different. So, I am in a position to have settings.gradle in each module. No harm in that.

But, the problem comes when we add a core module with some dependencies. We are to add that module in lot of overlay settings.gradle files.

To handle such scenarios, I am having one common WrapperRootProject. The build.gradle of WrapperRootProject will add the actual root project (project-d in case of Client-1) as dependency.

The WrapperRootProject in which I have paths.txt file to list the paths of all the modules. In settings.gradle of WrapperRootProject, I have to include only the projects that are dependencies of the actual root project (project-d).

Some programming logics, I am writing in WrapperRootProject/settings.gradle to infer the DAG hiearachy of the project-d…

Is it the best way to solve this scenario?

Pls advice