Maven At Work
To illustrate how you use Maven, I present it here in the context of the sample SudokuServer application. The application consists of two projects and a parent pom.xml file that ties the multi-module build together. The SudokuSolver project generates a .JAR artifact and the SudokuServer project generates a .war artifact. SudokuServer depends on SudokuSolver as well as on a bunch of third-party packages.
The pom.xml files of SudokuSolver and SudokuServer (Listing One and Listing Two, respectively) inherit from the pom.xml file (Listing Three) in the root directory. This lets you put all the common information and metadata in one place. The inheriting POM files specify a <parent> element that identifies the parent POM in the repository by group id, artifact id and version. The POM inheritance mechanism is not directly related to multi-module builds.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>GigiZone</groupId> <artifactId>Sudoku</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>SudokuServer</artifactId> <packaging>war</packaging> <dependencies> <!-- Internal dependency on another module --> <dependency> <groupId>GigiZone</groupId> <artifactId>SudokuSolver</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <!-- 3rd party dependencies available from the public repository --> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.0.4</version> <scope>provided</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.9</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>1.2.6</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>1.2.6</version> <scope>compile</scope> </dependency> <!-- SUN dependencies that must be cannot be distributed from public respositories and should not be deployed to the web container (hence the scope is 'provided') --> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.4</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jsp-api</artifactId> <version>2.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.1.2</version> <scope>compile</scope> </dependency> <!-- Test only depdendency (should not be deployed, hence the scope is 'test') --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
The POM of SudokuSolver is simple as it gets. It specifies its <parent>, its <artifactId> and its <dependencies>. The group id and version are inherited from its <parent> and the <packaging> defaults to "jar". The dependencies include only junit for testing purposes (note the "test" scope). SudokuSolver has unit tests in the src/test/Java directory, but thanks to the standard directory layout there is no need to specify it explicitly. Maven finds them and invoke the tests on its own accord.
The POM of SudokuServer is a little bit more involved. This component generates a .war file and it depends on quite a few components. In addition to <parent>and <artifactId> it specifies a <packaging> element ("war") and the <dependencies> element contains dependencies with different scopes. SudokuServer depends on SudokuSolver and a bunch of third-party modules (scope: compile). It also depends on Sun's servlet-api, jsp-api and jstl jars, but they will be provided by the web container (Tomcat in this case) hence the scope is "provided". Finally, it depends on junit for testing purposes.
The root POM provides common metadata used by both modules. It specifies a <packaging> element ("pom"), so its artifact is the pom.xml file itself, which is stored in the repository so inheriting projects can locate it. It specifies also a <url> and <developers> elements that can be used for documentation and site generation.