This message was deleted.

Hello, we are actually using setup as you describing it, with the api and impl modules. From gradle perspective there is nothing special, it is just modules as any other, we just use non written guidelines like nothing except from wiring module should have dependency on impl modules, impl modules have api module as api (configuration) dependency, some exceptions are that we sometimes have dependency on impl modules testFixtures to help with testing and reuse some mocks. Other modules should have dependency just on api modules if they need it and get the implementation injected from wiring module, either by something like spring or even manually works as wiring module has to have dependency on basically everything, So it should be as lightweight as possible as it can be recompiled a lot. It could be avoided by putting all modules just on runtime classpath and wiring using reflection (like spring do), but I remember there was some bug in intellij which was not recompiling modules if they were only on runtime classpath and I am not sure if it got fixed or not.

Hi @Dave562 have you seen improvements in full build time in your project? We’re also following this same api and impl approach but we’re not seeing much improvement in full build time. The code we’re moving out from app module is having very low reduction in build time as compared to new modules are getting created. In short, New module are taking more time (20-25 secs) while app is still having very few seconds benefit. in build time. Please let me know if you know what could be the reason.

Worth a watch https://www.droidcon.com/2022/11/15/modularization-flatten-your-graph-and-get-the-real-benefits/

Hello @Vikas Rai I am actually not sure it is quite long time since we did that change and it was not only change. I don't think it can actually help with full build time (it might even prolonger it in case of large number of modules and parallel build because of context switching I guess). Where we saw improvement was incremental builds because gradle did not have to rebuild everything but just subtree of modules which had dependency on changed module.

Thanks @Peter @Dave562