On Tue, May 17, 2011 at 3:50 PM, Russ Tremain <ru...@releasetools.org> wrote:
> 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.
Heh, that's the original use case I had when I started the plugin.
Mostly I didn't want to have to have key configuration of some
manipulations external to my pom in an assembly.xml. Glad you like the
plugin ;-)
>
> -Russ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
