12

I have a hard time do understand when to use composite builds vs multi-module builds. It seems both can be used to achieve similar things.

Are there still valid use cases for multi-module builds?

helpermethod
  • 59,493
  • 71
  • 188
  • 276

2 Answers2

7

In my opinion, a multi-module build is a single system which is built and released together. Every module in the build should have the same version and is likely developed by the same team and committed to a single repository (git/svn etc).

I think that a composite build is for development only and for use in times when a developer is working on two or more systems (likely in different repositories with different release cycles/versions). eg:

  • Developing a patch for an open source library whilst validating the changes in another system
  • Tweaking a utility library in a separate in-house repository (perhaps shared by multiple teams) whilst validating the changes in another system
  • A fix/improvement that spans two or more systems (likely in separate repos)

I don't think that a composite build should be committed to source control or built by continuous integration. I think CI should use jars from a repo (eg nexus). Basically I think composite builds serves the same purpose as the resolve workspace artifacts checkbox in m2e

Please note that one of the restrictions on a composite build is that it can not include another composite build. So I think it's safer to commit multi-module builds to source control and use composite builds to join them together locally for development only.

These are my opinions on how the two features should be used, I'm sure there are valid exceptions to the above

lance-java
  • 25,497
  • 4
  • 59
  • 101
  • 1
    My organization for example needs to move from monolithic repo to standalone libs. Composite builds create the flexibility needed to transition. – Duncan Calvert Jun 27 '17 at 19:39
  • Well we use multiproject on webpieces and CI time is near 5 minutes!!!! this sucks. we use composite in a monorepo (on leaf nodes) on a MUCH larger project and CI time is generally 1 minute. multiproject builds are very annoying building from scratch when you just change one leaf node and it has to build the F'ing world. – Dean Hiller Aug 04 '22 at 11:51
1

We use our own monorepo with monobuild-type detection and use composite builds for CI and CD to staging (any microservices that end up building from your changes auto-deploy to staging). I disagree that composite builds are just for development as we use it to get to production in a monorepo/monobuild.

multi-project build estimated time at Orderly Health is about 15-20 minutes based on webpieces 5 minutes AND based on modifying a library in OrderlyHealth that affects EVERY project takes about 15 minutes.

Instead, we detect projects changed, what leaf nodes depend on it and all leaf nodes are composite projects pulling in libraries that pull in libraries and the general average build time is 3 minutes. (That is a 5x boost right there on build time).

later Dean

Dean Hiller
  • 19,235
  • 25
  • 129
  • 212