why I love the maven-dependency plugin
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.
-Russ
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: why I love the maven-dependency plugin
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
