In a typical J2EE environment, a WAR is packaged within an EAR for deployment. The WAR can contain all its dependent JARs in WEB-INF/lib but then the EAR can quickly grow very large if there are multiple WARs, due to the presence of duplicate JARs. Instead the J2EE specification allows WARs to reference external JARs packaged within the EAR via the Class-Path setting in their MANIFEST.MF.
The Maven WAR and EAR Plugins do not directly support this mode of operation but we can fake it through some POM and configuration magic. First you need to tell Maven to exclude the dependent JARs and add references to them in the MANIFEST.MF instead. This goes into your WAR project's pom.xml:
<project> ... <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <!-- In version 2.1-alpha-1, this was incorrectly named warSourceExcludes --> <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> </configuration> </plugin> </plugins> </build> ... </project>
Here's another variant of the above example, but this time we use <packagingIncludes> to select a few JARs to be included in the WAR. This is useful when there is a need to package a small, but non-empty, subset of JARs into the WAR. When making an EAR of skinny WARs, one wants to package all of the JARs into the EAR. Sometimes a list of JARs must be packaged into the WAR though in order for it to work properly, like with tag libraries.
<project> ... <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <!-- Use this to include a selection of jars that will be included in the WAR --> <packagingIncludes>WEB-INF/lib/my-tag-library.jar,**/*.xml,**/*.properties,**/*.class,**/*.png,**/*.css,**/*.js,**/*.jsp</packagingIncludes> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> </configuration> </plugin> </plugins> </build> ... </project>
Next we need to change the EAR project's pom.xml to package those dependent JARs in the EAR. Notice that we package everything into a lib/ directory within the EAR. This is just my own personal preference to distinguish between J2EE modules (which will be packaged in the root of the EAR) and Java libraries (which are packaged in lib/).
... <build> <plugins> <plugin> <artifactId>maven-ear-plugin</artifactId> <version>2.3.2</version> <configuration> <defaultLibBundleDir>lib/</defaultLibBundleDir> </configuration> </plugin> </plugins> </build> ...
Now the painful part. Your EAR project's pom.xml needs to list every dependency that the WAR has. This is because Maven assumes fat WARs and does not include transitive dependencies of WARs within the EAR.
.... <dependencies> <dependency> <groupId>com.acme</groupId> <artifactId>shared-jar</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>com.acme</groupId> <artifactId>war1</artifactId> <version>1.0.0</version> <type>war</type> </dependency> <dependency> <groupId>com.acme</groupId> <artifactId>war2</artifactId> <version>1.0.0</version> <type>war</type> </dependency> </dependencies> ...
Your EAR will contain something like this:
. |-- META-INF | `-- application.xml |-- lib | `-- shared-jar-1.0.0.jar |-- war1-1.0.0.war `-- war2-1.0.0.war
Our users have submitted alternatives to the above recipe on the Wiki.