Migrating from multi-project+ git submodules to composite builds +multiple git repos

Hello!

I am in the process of re-arranging a multi-project gradle build based on about 100 projects + git submodules. The project contain several jar and war modules.
I wanted to brainstorm a bit with someone with experience opinions in this field also regarding the correct usage of gradle.properties
The current structure of of the project is as follow (questions at the bottom):
main-project-repo-root
- .git
- README.md
main-project-repo-root\main-project-eclipse-root
- .project
- build.gradle
- gradle.properties
- settings.gradle

main-project-repo-root\main-project-eclipse-root\sub-project1-repo-root
- .git (submodule)
- README.md
main-project-repo-root\main-project-eclipse-root\sub-project1-repo-root\sub-project1-eclipse-root
- .project
- sub-project1.gradle
- gradle.properties

The content of settings.gradle of the main project has someting like this to load subproject placed in the above structure and to use a build file with the same name as the project name:

rootProject.name = 'main-project'
include 'sub-project1'

rootProject.children.each {project ->
    String fileBaseName = project.name
    String projectDirName = "$fileBaseName/$fileBaseName"
    project.projectDir = new File(settingsDir, projectDirName)
    project.buildFileName = "${fileBaseName}.gradle"
    assert project.projectDir.isDirectory()
    assert project.buildFile.isFile()
}

Also, the build file of the main project injects a lot of stuff in the sub projects this is just a little example:

allprojects {
	apply plugin: 'eclipse'	
    group = 'my-group'
    repositories {    
	    jcenter()
	    mavenCentral()
	}
}

    subprojects {
    	apply plugin: 'java'
    .....
    }

QUESTIONS:

  1. Composite build directory structure.
    I would personally go for a “parallel structure” like the following, since composite builds implies that each project can exist on it’s own. This is because the sub-build could be already checked out and present in the eclipse workspace.
    On some presentation from gradle I have seen the habit of checking out the sub-builds in a directory “modules” under the main build and having that directory “excluded” in .git ignore. Any reason for choosing this approach?

main-build-repo-root
- .git
- README.md
main-build-repo-root\main-build-eclipse-root
- .project
- build.gradle
- gradle.properties
- settings.gradle (includeBuild("../../sub-build1-repo-root/sub-build1-eclipse-root")

sub-build1-repo-root
- .git
- README.md
sub-build1-repo-root\sub-build1-eclipse-root
- .project
- sub-build1.gradle
- gradle.properties

  1. Using non custom gradle build file.
    Currently we have renamed all build file to match the name of the subproject (to be able to see the difference when multiple are open in eclipse) i.e.:

sub-build1.gradle

I guess this won’t work with composite builds? Is there a way to tell composite build what is the name of the build file of the sub-build and also when running the build from the sub build, is there a way to tell to use a differen build file. Maybe using the gradle.properties?

  1. Best practice of what to put in gradle.properties.
    Since we are undergoing a major restructuring, I was wondering when it’s a good idea to put values in the property file instead of the build file or settings file.
    i.e. having the version number in the property file I thinks makes it more easy to automatically increment that number (i.e. in association with git flow release start).
    Still version number can be also kept in gradle.build. So what is a “proper usage” of property files.
    I am also planning to list all repos url of the sub builds and include them dynamically if they have been checked out. Would this list of repos url be in the property file or the settings file of the main build?

  2. Injecting configuration in composite builds
    Is it possible to perform the same kind of configuration and task injection like in multi-projects builds?

Thanks to anybody that is eager to discuss this subject

Regards