We have a 2 app repository and there are a large set of shared modules, not all are used across both apps, but the majority are. Ideally we would convert the shared modules into a composite build. The current setup is just a directory with direct

include

references. Our benchmarks show that we incur additional configuration load times in our build scans. Additional time to a cold configuration which would impact the ide-sync times by 25%. Is this an expected slow down or are we doing something wrong?

If I got you correct and you

include

one project into multiple builds, then this is definitely wrong, no matter what performance or anything else. A project should always only be part of exactly one build and if you need it in multiple, you should use composite build.

@Vampire can you explain if there is a technical concern about doing the

include: moduleA

or is it mainly just the correct layout to use a composite build Shared Modules directly included app1 include: moduleA include: moduleB app2 include: moduleA include: moduleC Shared Modules Composite Build app1 includeBuild: shared-modules (moduleA) include: moduleB app2 includeBuild: shared-modules (moduleA) include: moduleC

That's an extremely bad idea, yes, technically. The same project is built with different environment like different parent classloaders for the build scripts, different things injected through settings script and so on. Also iirc there could be very bad things happening if you start a build for app1 and app2 at the same time.

that makes sense, the potential different configurations that could be applied depending on the app's

settings.gradle.kts

Not only, the root project or the settings script or the

buildSrc

and so on could also influence the class loader ancestry of that subproject and thus cause problems.