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

Question

Consider the following enterprise application layering example:

1. project-services -> POJO Services layer
2. project-web -> Web application, depends upon 'project-services', deployed as a WAR
3. project-web-services -> Web Services , depends upon 'project-services', deployed as a separate WAR, not currently exposed over internet
4. 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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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"