Do composite builds make multi-module builds obsolete?

Question

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?

Answer 1

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