Multi project build with self-buildable subprojects

My aim is to write multiple gradle projects with various dependencies (project dependencies) on each other. Additionally, I also want to create a multi project build which builds all these projects. However I have little success.

The projects are not necessarily hierarchical (e.g.: project B and C may both depend on A but they does not depend on each other), so they need to address each other using relative paths. For the explanation I will assume that the directories of the projects (containing the build.gradle) are sibling directories (although it can be generalized to other cases).

Currently what I could achieve is either having a parent multi project build and subprojects define their dependency projects relative to the parent project; or not having a multi project build at all but be able to build every single projects separetly. The first case is relatively straight forward (as there are a lot of examples for this), for the latter here is an example project: https://github.com/kelemen/JTrim/tree/91b47f84f541efabf0f197cc2b2fc9efd0aedbc2

For convenience I have copy-pasted a gradle.build file from there:

apply plugin: 'java'
  repositories {
    mavenCentral()
}
  dependencies {
    compile project(':..:jtrim-async')
    testCompile group: 'junit', name: 'junit', version: '4.10'
}

My question is: Is it possible to have multiple self-buildable projects with another gradle project which builds all of them? If not could this be a feature request? :slight_smile:

Can you explain what exactly you mean by “self-buildable”? If project A has a project dependency on project B, the two projects have to be tied together with a ‘settings.gradle’. The directory layout, however, is pretty much freely configurable.

Future Gradle versions will blur the line between project dependencies and external dependencies, making it easier to work on a subset of projects.

I mean that I can “cd” to individual packages and execute a successful “gradle build” for that particular project (which might have project dependencies). Currently if I created a multi module project, then I could not build the individual packages without the need to reference the multi module project. (unless I don’t have multi module project).

Consider the following directories: “rootdir/project1”, “rootdir/project2”. Assume that project1 depends on project2. If I reference the dependency in “rootdir/project1/build.gradle” as “:project2”, then it will build successfully from the build config in “rootdir/build.gradle” but not from “rootdir/project1/build.gradle”. That is, I could not figure out what to write in the settings.gradle of “project” for this to work. If I write the dependency as “:…:project2”, then it will not work from “rootdir/build.gradle”. This of course might very well be due to my lack of knowledge in Gradle but this is the issue I could not resolve.

With a classical hierarchical project layout like you have just described, you’ll get the ability to cd into a subproject and run the build from there for free. The reference ‘:project2’ is correct. Note that this denotes the logical path of project2 in the build, not where it is located on disk. The latter is exclusively configured in ‘settings.gradle’. But as I said, in your case the defaults should just work. Otherwise, have a look at the many sample builds available.

From what you say, I believe that this should work: https://github.com/kelemen/basic-gradle

However if I cd into the “project1” directory and run “gradle build”, the build fails (others build successfully). Despite I having project2 listed as “…:project2” in the settings.gradle and “:project2” as a dependency in “project1/build.gradle”.

‘basic-gradle/project1/settings.gradle’ is incorrect. You can just remove this file.

Thank you for your answer, removing settings.gradle does help. However it leaves me wonder how Gradle knows where to look for project2? Is it always looks in sibling directories or tries children as well? Regardless, I consider this question solved. Thank you for your answer again.

The Gradle User Guide explains the initialization logic of a Gradle build.

Thank you, this solves my question.