Maven dependency vs multimodule?

Question

Very new to Maven, can someone please explain to me the difference between using maven modules vs just adding a dependency to your maven project to another maven project in your workspace? When would you use one over the other?

Answer 1

A dependency is a pre-built entity. You get the artifact for that dependency from Maven Central (or Nexus or the like.) It is common to use dependencies for code that belongs to other teams or projects. For example, suppose you need a CSV library in Android. You'd pull it as a dependency.

A Maven module gets built just like your project does. It is common to use Maven modules for components that the project owns. For example, maybe your project creates three jar files.

Answer 2

A dependency can be thought of as a lib/jar (aka Artifact in Maven parlance) that you need to use for building and/or running your code. This artifact can either be built by your one of the modules of your multi module project or a third party pre-build library (for example log4j).

One of the concepts of maven is that each module is going to output a single artifact (say a jar). So in case of a complex project it is good idea to split your project to multiple modules. And these modules can be dependent on each other via declared dependencies. See http://books.sonatype.com/mvnex-book/reference/multimodule-sect-intro.html for example of how a web app is split to parent and child modules and how they are linked.

Answer 3

One of the most confusing aspects of Maven is the fact that the parent pom can act as both a parent and as an aggregator.

99% of the functionality you think about in Maven is the parent pom aspect, where you inherit things like repositories, plugins, and most importantly, dependencies.

Dependencies are hard, tangible relationships between your libs that are evaluated during each build. If you think of your software as a meal, it's basically saying A requires ingredient B.

So let's say you're preparing lasagne. Then your dependency chain would look something like this:

lasagne
    <- meatSauce
        <- groundBeef
        <- tomatoPaste
    <- cheese
    <- noodles

The key thing is, each of the above items (meatSause, groundBeef, cheese, etc) are individual builds that have their individual set of dependencies.

By contrast, the only section of your pom that pertains to aggregation is the modules section:

<modules>
    <module>meatSauce</module>
    <module>groundBeef</module>
    <module>tomatoPaste</module>
    <module>cheese</module>
    <module>noodles</module>
</modules>

Aggregation simply tells your build engine that it should run these 5 builds in rapid succession:

groundBeef -> tomatoPaste -> cheese -> noodles -> meatSauce

The main benefit of aggregation is the convenience (just click build once) and ensuring the builds are in the correct order (e.g. you wouldn't want to build meatSauce before tomatoPaste).

Here's the thing though: even if you organize the libs as standalone projects without module aggregation, your build will still come out the same provided you build in the correct order.

Moreover, both Jenkins and Eclipse have mechanisms for triggering builds if a dependent project has changed (e.g. changing groundBeef will automatically trigger meatSauce).

Therefore if you're building out of Jenkins or Eclipse, there is no need for aggregation