On Tue, May 17, 2011 at 3:50 PM, Russ Tremain 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:
>
>
>
>
> maven-dependency-plugin
>
>
> ${project.artifactId}-unpack-war-resources
> process-resources
> unpack
>
>
>
> com.foo
>
> ${project.artifactId}-resources
> ${someVersion}
>
> ${project.build.directory}/${project.build.finalName}
>
>
>
>
> ...
>
> 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:
>
>
>
> build-common-webapps
> com.foo
> 1.0
> ../../../build-common/webapps
>
> 4.0.0
> com.foo
> mywebapp
> war
> ${someVersion}
>
>
>
> 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