I have a flat multi-project setup with a directory called ‘master’, which contains the settings.gradle file. Can this directory name be changed to something else besides “master”? We may have many different multi-project setups and would like to name it something more like ‘-root’. Is this possible?
It is entirely possible. The drawback is that you will no longer be able to cd into a subproject directory and execute the build from there. (You’ll still be able to execute a subproject’s task from the master directory though, by specifying the full task path.)
If you’d like to keep the name for the root project as master it’s as simple as setting
rootProject.name = 'master'
in settings.gradle
Renaming the rootfolder then won’t affect the rootProject’s name
I guess maybe I should describe why I need it renamed in the first place. We are a big company and sometimes people will be working on more than 1 project at a time (project = single gradle multi-project where each multi-project contains 1 or more sub-projects). Also any 1 person may or may not be working on more than 1 sub-project in a multi-project. That user will be required to “check out” the sub-projects they are working on along with the “master” project for each project (we have to use the flat filesystem layout based on the source control system we use - it doesn’t allow anything to be checked in at the “root” level).
This scenario would cause a clash in a user’s eclipse workspace - they would have 2 directories named “master”, 1 for each project they were working on. I wanted to be able to change the name of this directory to “project-name-master” (or something else which includes the project name), that way it is clear which directory goes with which project.
ALL of the build logic is contained in the build.gradle inside of the master directory of a project. Most sub-projects don’t even have a build.gradle - all of the logic is driven through properties. Each sub-project has a gradle.properties which is read by the master build.gradle and then the build gets customized that way. The master build.gradle doesn’t even “live” inside each individual project - our source control system allows to “link” things from one project to another, so the build.gradle actually exists in its own project inside source control and is then linked to each project. Our source control system takes care of downloading it into each individual project when a project is checked out. This way only a certain set of users have access to change the master build.gradle and any changes to it get distributed immediately to all projects. Someone on an individual project can’t make changes to it since it doesn’t actually “live” inside their project.
When a developer is working on a sub-project they will only be building the particular sub-project locally (by using the Gradle tooling built into STS). A developer will never really execute the build from the master directory. Our CI servers will always execute the build from the master directory though whenever a change is checked into any of the sub-projects of a project.
I know you can change the eclipse project name of the master sub-project (by using a .project file) but what I need is the ability to change the name of the directory itself.
It’s a chicken-egg problem. The very first thing a (multi-project) build does is to search for settings.gradle - everything else (where any build-related file is located etc.) follows from that. The settings.gradle is searched for in parent directories and in a sibling directory called master. Until settings.gradle is found, Gradle knows nothing about the build (not even if it exists) and has no way of reading any build-specific configuration. That’s why the master name is hardcoded.
One way to solve the Eclipse name clashes would be to use separate Eclipse workspaces.
Currently, Gradle doesn’t deal very well with partial checkouts of builds. This will be a big topic of Gradle 1.2 and beyond.
Maybe instead of hard coding a directory name gradle could by default look in the parent directory, then all sibling directories until it found a settings.gradle.
Using separate workspaces wouldn’t really be all too productive, especially since developers are constantly working on multiple projects. It’s not the eclipse project name that clashes (that can be changed by changing the .project file. It’s the fact that now in a single workspace there could potentially be 2 directories named “master”.
I guess until gradle can support this I’ll have to figure put how to work around this.
Maybe instead of hard coding a directory name gradle could by default look in the parent directory, then all sibling directories until it found a settings.gradle.
I’m afraid this wouldn’t work. Imagine you have a single-project build and a multi-project build in a sibling directory. Gradle would find the settings.gradle of the multi-project build and build that.
The settings.gradle of the multi-project build in a sibling directory would not have an entry for the single-project build would it? Therefore when reading the settings.gradle in the multi-project sibling directory it would still execute as a single-project build since the multi-project build did not include it. Correct?
We can’t compile and evaluate settings.gradle files just to find out if we found an appropriate one. It has too many implications.
Changing the initial lookup strategy is unlikely going to solve this problem. Instead we are going to tackle the partial build problem heads-on.
Hi there, years have gone. Now we have exactly the same problem as Eric had. Eric, did you find a solution? Peter, did you succeed to tackle the problem?
thank you very much in advance John
Hi John - The solution we use is to have multiple eclipse workspaces for each multi-project. That has been working well for us. There’s nothing that can be done in Gradle itself to rename this “master” directory to something else.
Hope that helps!