Advice on creating Maven project structure - Multiple Modules vs Multiple Projects?

Question

Consider the following enterprise application layering example:

project-services -> POJO Services layer
project-web -> Web application, depends upon 'project-services', deployed as a WAR
project-web-services -> Web Services , depends upon 'project-services', deployed as a separate WAR, not currently exposed over internet
project-standalone -> Cron Jobs, depends upon 'project-services'

What would be the right approach for organizing this in Maven. Should I create a multi-module maven project? if 'project-services' is a Maven module, can it be shared with other three projects each of which is an independent deployable unit?

In my previous projects I have simply created 4 different Maven projects and never felt much need of anything else.

Want to validate whether there is a better way than what I have been doing previously.

score 2 · Accepted Answer · answered Feb 10 '12 at 12:58

You could actually do either approach. If it's really one big project, that you always want to build and release at the same time, a multi-module project is a good fit. You'd set it up like this probably:

pom project (top level project that would define all of the modules)
  jar project (project-services)
  war project (project-web)
  war project (project-web-services)
  project-standalone (wasn't sure if this was a jar, or just some scripts, etc)

So you'd only build and release off the root project, and it'd take care of all of the sub modules for you. They can each have dependencies on each other (just be careful of circular dependencies). And you'd pretty much be set to go.

The other option is separate artifacts altogether. The benefit there is a different release cycle. It's a good option for when you have a jar library that doesn't change often, but you update the war frequently.

And obviously, you could have a mix, so maybe the jar is standalone, but you have a multi-module project that contains the two war files. The benefit of maven is that it's flexible enough to handle whatever the business case you have for how these should be divided up.

score 1 · Answer 2 · answered Feb 11 '12 at 07:27

In my workplace we have many top level projects that share libraries (15 top level projects share 35 or so libraries). We went with the single project per library approach. Today, when we have to release all of them in one go, it's a nightmare.

Some problems we face:

Manually figure out dependencies
Have to run the release in proper order
One failure stops the entire release

If I had to d it all over again (I helped set all this up), I would use a single multi-module project. If nothing else, releasing everything in one go is a huge advantage. The projects might not look pretty in eclipse but thats not what you should be aiming for anyway.

The downside to one huge project is that you're often releasing artifacts that didn't have any changes. I understand the release issue, maybe in your case you actually change every artifact every time you're going to release...in which case it's less of a hassle. But sometimes when you just need to release one artifact, releasing them all with no changes is less than ideal. — Michael, Feb 12 '12 at 02:10

score 0 · Answer 3 · answered Feb 10 '12 at 13:06

I would certainly go with a single project with for modules to ensure that the used versions of common 3rd-party libraries matches.

Having a POM-project as the root and having all implementation and other artefacts share it is generally considered a good practice for everything but single-module projects.

score 0 · Answer 4 · answered Feb 15 '12 at 09:29

Since you have some direct dependencies between the modules I would also recommend on multi-module project.

What I often recommend is to consider the life-cycle of the modules. For example: if you would release the batch module far more often than the service layer it might make sense to split it apart. So you don't need to release (deploy) stuff that had no changes. Since batch is usually not deployed the same way as .war files. But that depends on the life-cycle of the service+batch modules.

In most cases the move side-by-side. So +1 for "one for all"

Advice on creating Maven project structure - Multiple Modules vs Multiple Projects?

4 Answers4