I have a general question about Maven\'s multi module project. When and why to go for it?
The answer of @Esko Luontola
Splitting the project into multiple modules is useful for example if the modules need to be deployed separately,..
could be misinterpreted. If you have modules which will be deployed separately, it's exactly the opposite. In such case, you should never create a multi-module build. This should be done via simple separate maven projects.
The idea of a multi-module build is if you have modules which belong together like an ear project which usually consists of several others like client, server, ejb, war, etc. This is usually handled via a multi-module build which means all modules have the same version number but can be accessed and used by other separately.
It seems that this question is more about software in general. Maven is just one way of doing it.
I will qoute a few lines from "Continuous Delivery", by Jez Humble
What is a component? This is a horribly overloaded term in software, so we will try to make it as clear as possible what we mean by it. When we talk about components, we mean a reasonably large-scale code structure within an applica- tion, with a well-defined API, that could potentially be swapped out for another implementation. A component-based software system is distinguished by the fact that the codebase is divided into discrete pieces that provide behavior through well-defined, limited interactions with other components. The antithesis of a component-based system is a monolithic system with no clear boundaries or separation of concerns between elements responsible for different tasks. Monolithic systems typically have poor encapsulation, and tight coupling between logically independent structures breaks the Law of Demeter.
...
Employing a component-based design is often described as encouraging reuse and good architectural properties such as loose coupling. This is true, but it also has another important benefit: It is one of the most efficient ways for large teams of developers to collaborate.
...
Many projects are fine with a single version control repository and a simple deployment pipeline. However, many projects have evolved into an unmaintain- able morass of code because nobody made the decision to create discrete compo- nents when it was cheap to do so. The point at which small projects change into larger ones is fluid and will sneak up on you.
...
Finally, it’s worth noting Conway’s Law, which states that “organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”4 So, for example, open source projects where developers communicate only by email tend to be very modular with few interfaces. A product developed by a small, colocated team will tend to be tightly coupled and not modular. Be careful of how you set up your development team—it will affect the architecture of your application.
I find amazing how lucid and accurate this last statement is. And I strongly recommend that book! :-)
There are some more use cases in which I will recommend using multi module maven project:
Your modules share the same dependencies, in this case you will specify all the dependencies in the main pom, and all the modules can enjoy it. ( No need to specify for each module the same dependencies.)
If you need to perform operations on multiple projects all together. ( I personally use it) , I create a package from all my projects, and ship it to a costumer, so I build them using the main pom , and package them as zip file using other maven plugin.
Splitting the project into multiple modules is useful for example if the modules need to be deployed separately, or in case of a library some consumers of the project need only a subset of the classes, or the developers of the library want to make a clear distinction between what is public API and what is private implementation. And with big projects it may make the code easier to keep in order, even if it the code could technically be all in the same module.