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...
- You have a DAO project
- The DAO project is a dependency of
the Service project
- 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
What is the use of multilevel Maven project?
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.
How are the Maven project maintained?
Much of the project management and build related tasks are maintained by Maven plugins. Developers can build any given Maven project without the need to understand how the individual plugins work. We will discuss Maven Plugins in detail in the later chapters.
What is groupId and artifactId in Maven?
3.1.groupId – a unique base name of the company or group that created the project. artifactId – a unique name of the project. version – a version of the project. packaging – a packaging method (e.g. WAR/JAR/ZIP)
What is Maven clean?
The Maven Clean Plugin, as the name implies, attempts to clean the files and directories generated by Maven during its build. While there are plugins that generate additional files, the Clean Plugin assumes that these files are generated inside the target directory.
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.
I've been happily using the Multi-module Enterprise Project layout from Maven by Example. Read it through for inspiration and work it into what works for you..
Menu
816
