1

In a nutshell, what I am trying to do is build a bunch of libraries and applications, all Maven projects, all at once. From what I understand a way to accomplish this just in one command line run of mvn package would be to create a multimodule project that will list each module that I would like to build, throw them in the Maven reactor, and build.

Following examples in the Maven book it seems that normally a multimodule pom sits in a directory above the individual modules. However it is also normally the case that a parent pom sits in a directory above the modules, which raises the question, is it normally the case that a multimodule build should also be a parent? I think not; however I wonder why I am running into this funny design quirk.

So, I'm wondering the right way to set this up. I see the following conventions / requirements:

  • The multimodule pom must have knowledge of where the other modules live on disc. Since it is actually doing the build from source it can't simply rely on already installed versions (since it's installing them!)
  • The parent doesn't actually have to be a physical directory up although that would be preferable. I see this as the convention best to break.
  • Really the individual libraries/application shouldn't even need to know they are being built as part of a multimodule build.

How is this usually set up in a multimodule build? Is there a simpler way to manage building multiple Maven projects all at once?

djechlin
  • 59,258
  • 35
  • 162
  • 290

2 Answers2

1

I put all the individual modules within the root module. Some software has trouble with multiple layers of hierarchy.

To make a child module refer to it's parent on the same level:

<parent>
    <groupId>com.domain</groupId>
    <artifactId>xyz</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../xyz/pom.xml</relativePath>
</parent>

I suggest you do not put anything in the multimodule (e.g. properties) that individual modules need to inherit. If you do, you won't be able to build the other modules independently.

Community
  • 1
  • 1
mikeslattery
  • 4,039
  • 1
  • 19
  • 14
  • +1 i found that eclipse has performance issues with nested modules. – asgoth Dec 31 '12 at 17:24
  • If you have problems to resolve module inter dependencies than your multi-module build is wrong. – khmarbaise Jan 01 '13 at 00:18
  • `Also realize that inter-module dependencies are resolved using the local repository (not target directories).` - not true as of Maven 3. If a module in the build has a dependency on another module in the build, the module's build directory will be used to satisfy the dependency. I can't immediately find the docs on that, but it's easy to prove in practice. – Ryan Stewart Jan 01 '13 at 00:52
  • You're both right. I tested mvn package and it worked great. I removed that part of my answer. – mikeslattery Jan 02 '13 at 00:40
0

I would go so far as to say that this is the fuzzy part of the "conventions". The documentation, and common sense, both suggest that project aggregation ( aka multi-module builds ) and inheritance are two different mechanisms provided to handle different use cases.

At the same time, it seems that there is a de facto convention ( yeah, I know ) of combining both the project aggregation and inheritance parent roles into a single pom. In fact, both the element of the parent declaration and the module element of the project aggegration mechanism seem to steer the use toward this combination.

Personally, I find it very usefull to separate the parent pom out on a regular basis. And I also find it useful ot locate parent pom in a totally separation location in my source control, and thus my folder structure. However, it rarely seems useful to locate builds that are a part of the same multi-module build structure in source control / folder structure. Perhaps this is even a good measure of whether something should be included in the same aggregate build; if it seems to deserve collocation in the source folder structure, then perhaps its a strong candidate for aggregation.

The only thin I am sure of is that these things are worth sorting out a head of time. And it's probably better to error on the side of not creating monolithic build structures . . . it's very hard to deal with a huge lump of aggregated, parent child build modules that isn't really necessary. On the other hand, aggregating individual builds to run together is a functionality provide at higher levels, such as the CI build server. So, I guess I might suggest erroring on the side of more independence.

chad
  • 7,369
  • 6
  • 37
  • 56