Enterprise Java Development@TOPIC@
Maven modules boundaries are highly influenced by the re-usable artifacts that must be produced
If you have many .jars, you likely have many maven modules
If you have few but large .jars, you likely have few but large maven modules
If you require different types of artifacts, you likely have different maven modules
Maven can be used in multi-module configuration
Many maven modules share the same configuration needs -- could lead to duplication
POM Inheritance helps mitigate duplication issues
Common properties can be defined in parent pom
<project>
<groupId>info.ejava.examples</groupId>
<artifactId>examples-root</artifactId>
<version>5.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Student Root</name>
<scm>
<url>https://github.com/ejavaguy/ejava-student/tree/master</url>
<connection>scm:git:git@github.com:ejavaguy/ejava-student.git</connection>
<developerConnection>scm:git:git@github-ejavaguy:ejavaguy/ejava-student.git</developerConnection>
<tag>HEAD</tag>
</scm>
...
In the above example -- the parent pom is defining the CM repository for all sub-modules
Child projects can inherit from a parent pom
<project>
<parent>
<groupId>info.ejava.examples</groupId>
<artifactId>examples-root</artifactId>
<version>5.0.0-SNAPSHOT</version>
</parent>
<groupId>info.ejava.examples.javase</groupId>
<artifactId>javase</artifactId>
<packaging>pom</packaging>
<name>JavaSE</name>
...
In the above example, the javase project inherits the CM configuration from the parent
If you include a relativePath to the parent -- changes to parents in your build environment will be immediately reused without having to install them into the localRepository.
Use the relativePath element to specify an alternate
Use relativePath element to specify a relative path to the parent pom
<relativePath>build/dependencies/pom.xml</relativePath>
Use an empty relativePath to specify the pom in the parent directory is not the relative location of this project's pom
<relativePath/>
Specifying a relativePath to ".." is redundant information since that is the default value.
Be careful not to attempt to blindly merge all project declarations into a single parent pom. This can bloat the inheriting children with unwanted dependencies and actions, cause slower builds, and can even break a build. When in doubt -- push active declarations (like dependencies and plugin declarations) to the leaf modules and leave only passive definitions (like properties, dependencyManagement, and pluginManagement) in the parent.
Parent modules can be created to delegate build commands to a group of child modules
Child modules can be physically placed anywhere, but commonly in immediate sub-directories named after their artifactId
<project>
<parent>
<groupId>info.ejava.examples.ejb</groupId>
<artifactId>ejb</artifactId>
<version>5.0.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>ejbsessionBank</artifactId>
<packaging>pom</packaging>
<name>EJB::Session EJB Bank Example</name>
<description>
This project is the root project for the core session bean example.
</description>
<modules>
<module>ejbsessionBankImpl</module>
<module>ejbsessionBankEJB</module>
<module>ejbsessionBankWAR</module>
<module>ejbsessionBankEAR</module>
<module>ejbsessionBankTest</module>
</modules>
</project>
The example above has several child modules that it will build in the order they are specified.