I have multiple app projects of of roughly this layout:

• example app (Java)
  • Java Wrapper with additional functionality
    • C++ + Shallow Java Wrapper
• 2nd example app (flutter)
  • flutter wrapper
    • Java Wrapper with additional functionality
      • C++ + Shallow Java Wrapper
• 3rd example app
  • flutter wrapper
    • Java Wrapper with additional functionality
      • C++ + Shallow Java Wrapper

All apps share the same main dependency (java Wrapper with additional functionality) and its dependency tree. Now I am developing on each app all the way down to C++ code. They are managed as git submodules in their respective parent project.

As there is a high change rate along the whole process, I want the final example to be built for testing from all sources.

I tried several approaches for tying this together into one gradle build:

1. Preferred (but failing) solution: settings.gradle in each project, each project only includes direct dependencies

Now I want this full tree to be managed in one flutter build. So I add the direct dependencies in each projects settings.gradle, just to learn that gradle only supports one toplevel settings.gradle. So this does not work. The presented solutions in aforementioned question mostly try to emulate support for multiple settings.gradle files.

2. Functioning but Ugly: Add all dependency projects are included in the toplevel settings.gradle

Do I really have to include all subprojects manually in the toplevel settings.gradle, when each of the subprojects knows its dependencies perfectly fine? Furthermore, since there are multiple projects depending on this, do I have to do this manually for each of them?

(And don't even get me startet about gradle not telling me, I have a wrong projectDir because I got a typo in the 100rth level of recursive descend!)

3. Probably Working Solution: Use composite builds

This will trigger the builds but now I have to resolve the build artifacts instead of the projects. So same problem with other artifacts.

4. Probably Working solution: Publish dependency projects to a maven (or other) repository and pull that into the app

I did not try this because I find the idea abhorent: I want to test one small change in the C++ code and now have to push that to a repository and potentially do the same on every project above? This works for a stable project but not for flexible exploratory development. Sure, I want to publish something at the end but I don't want to publish every little step in between.

This left me wondering: Am I doing something unusual? I mean: is there nobody who has the same requirements that gradle does not seem able to fit:

1. live updates from all the way down to quick test local changes
2. no repeating of transitive dependencies on the toplevel

What is the common practice in this case?

After Lukas Körfer's comment I took a closer look at composite builds again and noticed that I had a misconception about them. I did not understand that their dependency resolution will solve the finding of the build artifacts for me.

Now I use the composite builds to tie together the whole build while using

implementation 'my.group:project'

to import the code of the subprojects and

includeBuild '../path/to/subproject/'

to pull them in.