0

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?

Nobody moving away from SE
  • 9,347
  • 3
  • 45
  • 92
  • *no repeating of transitive dependencies* I guess you are talking about the `include` statements in the `settings.gradle` file, but please note that you do not define dependencies this way, but projects inside the build. At this point there is no hierarchy and therefore, no dependencies. If your projects are really strongly discoupled at each level of your hierarchy, use composite builds. Otherwise, think about a more flat project hierarchy. – Lukas Körfer May 22 '19 at 08:59
  • @LukasKörfer I am not sure if they would count as strongly discoupled. As I described, I'd like to codevelop the subprojects iteratively without having a large publish loop in between. As it looks to me, the composite builds would result in locally available .aar files that I would have to find in the toplevel project again, so I did not win anything. `you do not define dependencies this way`: I am new to gradle. All I want to say is: each project needs something from the subprojects. Therefore, they look like dependencies to me, no? – Nobody moving away from SE May 22 '19 at 09:14

1 Answers1

0

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.

Nobody moving away from SE
  • 9,347
  • 3
  • 45
  • 92