I use the maven-dependency plugin for jar and war packaging.
It is flexible and non-judgmental.
This is particularly important when you are converting a large
project over to maven and cannot follow some maven conventions - you
may be constrained to recreate identical or near-identical artifacts
using maven.
Here is a pattern that works for wars:
1) create a war-resource jar that has all libs and resources
pre-configured for dumping to WEB-INF. You can use the dependency
plugin to create the exact names you need to match the project you
are converting. For example, you may need to change the name of an
artifact. Or you may need to eliminate version numbers in the names
of the artifacts.
The maven-dependency plugin can do it all. You can use multiple
executions to sweep in artifacts - perhaps one with version names,
one without, and then explicit renaming of any remaining artifacts.
Use antrun to do any additional processing - e.g. to copy or rename a
resource. (The standard maven resources plugin will not do this for
you).
2) In the war project, which automatically uses the maven-war
plugin, just unpack your resource jar using the maven-dependency
plugin unpack goal. Do not declare any dependencies in the war pom,
as they will get automatically copied without possibility for
intervention.
The unpack specification can be declared in a parent pom, which makes
your war packaging project very small.
For example, in the parent pom:
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>${project.artifactId}-unpack-war-resources</id>
<phase>process-resources</phase>
<goals><goal>unpack</goal></goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.foo</groupId>
<artifactId>${project.artifactId}-resources</artifactId>
<version>${someVersion}</version>
<outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
...
The only trick is to use a standard name for the associated resource
jar (${project.artifactId}-resources in this example).
The war pom is now trivial, for example:
<project>
<parent>
<artifactId>build-common-webapps</artifactId>
<groupId>com.foo</groupId>
<version>1.0</version>
<relativePath>../../../build-common/webapps</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo</groupId>
<artifactId>mywebapp</artifactId>
<packaging>war</packaging>
<version>${someVersion}</version>
</project>
3) create separate projects for compiling the war code, jsps, or any
other work. These projects are then added to the resource package
(as jars, or unpacked as classes, or whatever you need).
4) wire the projects together using a multi-project pom, creating
sub-directories for the auxiliary packaging and build poms.
Some advocate the use of the assembly plugin for doing this sort of
work, but I prefer the simplicity of the dependency plugin approach,
reserving the assembly plugin for producing final distribution
bundles.
-Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
