Menu
Consider the following enterprise application layering example:
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.
866
Advantages of a Multi-Module ProjectIt provides a great ability to build all sub-modules only with a single command. We can run the build command from the parent module. While building the application, the build system takes care of the build order. Deployment of the applications gets very convenient and flexible.
The best practice used when building Content Packs is called Maven Bill of Materials (BOM), where there is a root Maven project (pom. xml) that defines common dependencies, versions, properties, etc.
A Maven module is a sub-project. To create a Maven module you will need to already have a Maven project available. The parent project must have its Packaging option pre-configured to pom, for a module to be created and associated with it.
A multi-module project is built from an aggregator POM that manages a group of submodules. In most cases, the aggregator is located in the project's root directory and must have packaging of type pom. The submodules are regular Maven projects, and they can be built separately or through the aggregator POM.
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.
64
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:
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.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
