If you list all projects in settings.gradle
then the default behavior is that all projects would have to be configured. The time spent during the configuration phase will improve over time with the new configuration model.
Another option would be to make teamA
and teamB
separate multi-project builds with their own settings.gradle
. The only shared module you’d need would be the common
module. Depending on how frequent the code of common
changes, you could publish its binary artifact and refer to it from teamA
and teamB
by declaring an external module dependency.
You might also want to think about breaking up the single source tree by team. As far as I understand your scenario, developers usually work on team A or B but most of the times not on both teams. Having the code in separate VCS repositories also helps clarify project boundaries. The common
module would then live in its own VCS repository as well. The downside is that shared modules would have to be published. In the long run we want to provide a hybrid approach by substituting module dependencies by project dependencies and vice versa (even if the code lives in different VCS repositories). This work has been started with 2.5. Please refer to the release notes for more information.