New project with Maven2

Question

What's the recommended way to use Maven for a project that might grow large in the future? I work with Eclipse and I see different approaches. Some use one project with no sub modules, and some Like mahout for example, have different sub-projects for different modules (e.g., core, math, examples, etc.). You can see it in this link: http://svn.apache.org/repos/asf/mahout/trunk/

Is there any advantage preferring one over the other?

Thanks.

Answer 1

It's recommended to use modules cause usually in a large project you have reltionships between the modules which are handled by Maven. On the other hand the related parts are related to each other so a reactor build is a good way and of course the release system of Maven give you many things to support you in your project ( branching etc.).

Answer 2

The decision to split a project into modules should be driven by the way you want to design and maintain your application. Maven itself will work well whether you choose to create a multi-module project, or lump everything together in a single module. So then the question becomes, what are the advantages/disadvantages of splitting your application into multiple modules.

Some drivers for splitting your app are purely technical:

• Generation of separate client and server artifacts
• Generation a command line version and a web app version
• Module dependency relationships

In other cases, it is more design related concerns will drive you to split up your application. This is especially important if your concern is an application that will grow over time. In these cases, you want to separate your application into specific areas of concern, and have defined service boundaries through which modules interact. This allows you to evolve individual modules over time, while minimizing the effect on the remaining parts of the application.

Note that maven is especially good with large multi-module projects, because of the support it provides for dependency management and resolution.

Answer 3

Modules are really a core concepts with Maven (and are well supported) and the obvious advantage of modular builds is... well, modularity.

Pros:

• Allows better separation of concerns.
• Promotes, enforces modular design of code.
• Gives you finer grained control of what you "apply" to each parts.
• Allows to work on subparts of the code in isolation of the other parts.
  • Using binary dependencies speeds up compilation (vs compiling a whole monolithic project).
• Allows users to depend on subparts of your application only.

Cons:

• If not needed, multiple modules would induce more maintenance than a monolithic project.

So, Maven supports and promotes modular builds, that's part of the design. And in some case, you actually don't even have the choice because of the one (main) artifact per module golden rule: if you want to distribute an application as different parts, or to assemble several parts of an application (e.g. a client JAR and and a server JAR, or JARs in a WAR, or some EJB-JARs and WARs in a EAR), you must create dedicated modules for them (Maven can't produce a WAR and an EAR from a same module).

To sum up, modularity of your build is somehow driven by the nature of your application, it might just be required. But if your app is not modular by nature (say you develop a swing client), you can use a single module. Divide it as needed when things become too complex, too big.