Question

What is the best way to split up a large enterprise project in Maven?

It’s easy enough to understand how to partition things vertically like this…

1. You have a DAO project
2. The DAO project is a dependency of
   the Service project
3. The Service project is a dependency
   of the web project.

Does anybody have input on best practices in partitioning/splitting up really large projects in Maven.m

Answer 1

Some things that have helped me

• Use multi-module projects for projects that are related and only projects that are related. An EJB that exists only in a single EAR is a candidate for this. A bo layer that is used by an EJB and a client app is not.
• One Artifact per pom, one deployable per multi-module project Do Not Waste Time trying to get around this.
• Create dependency poms that include common sets of dependencies. That way you can include your DAO, your jdbc driver and your ORM tools with a single dependency. It also makes upgrading dozens of projects to the newest version of your ORM or DAO that much easier.
• Create builder projects that exist only to run assembly and create deployment sets. This will keep multiple parts of your project in sync. Assembling large complex enterprise apps is often complicated enough that you need a mix of maven, shell scripts and/or ant:run tasks plus dozens of profiles. Putting the mess in a project far away from your code will contain the mess before it spreads.
• Create tester projects for continuous integration use. Define your web and app servers in those poms as well as the test deployment info. Use of parent projects and common properties files will make testing deployment changes easier.
• Define distributionManagement in a parent pom only if it is possible to make all sub-projects a child (or grand-child) of it.
• Try not to depend on large files (EAR, WAR) being stuffed into your repository on every build. Removing the need for a 175mb WAR to be pushed to nexus on each snapshot improved our build times.
• Try to define things as few times as possible. A DRY build is a happy build. Having 30 poms with source-version 1.5 or 30 poms using junit 3.8.2 is going to make upgrading to java 6 or junit 4.4 that much harder.

Hope this helps.