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.