如何设置具有多级模块的项目以进行本地开发

Question

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?

Answer 1

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.