Mapping strategy for libraries in the WAR/EAR plugin

[Stephane Nicoll <st...@gmail.com>]

Hi,

I am starting using the WAR plugin extensively as a user this time and
I'd like your insight about the addition of a mapping strategy in the
WAR/EAR plugin.

The worst case I can see is when you have SNAPSHOT dependencies and
you download a new SNAPSHOT without calling mvn clean. Since Maven
will copy the library with the "full name" (i.e. with the build
number), you end up with *two* versions of the library in your
WEB-INF/lib.

Am I missing something obvious here? Also, we have several use cases
where copying the libraries as ${artifactId}.${type} (e.g. without the
version and/or the classifier) would be handy.

The assembly plugin already provides this so:

1. What do you think about having this feature in WAR/EAR?
2. Is the mapping thingy in the assembly plugin can be reused? (by
putting it to shared or something)

Thanks,
Stéphane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Mapping strategy for libraries in the WAR/EAR plugin

[Stephane Nicoll <st...@gmail.com>]

Hi,

On 3/7/07, Eric Redmond <er...@gmail.com> wrote:
> On 3/7/07, Stephane Nicoll <st...@gmail.com> wrote:
> >
> > Hi,
> >
> > I am starting using the WAR plugin extensively as a user this time and
> > I'd like your insight about the addition of a mapping strategy in the
> > WAR/EAR plugin.
> >
> > The worst case I can see is when you have SNAPSHOT dependencies and
> > you download a new SNAPSHOT without calling mvn clean. Since Maven
> > will copy the library with the "full name" (i.e. with the build
> > number), you end up with *two* versions of the library in your
> > WEB-INF/lib.
>
>
> This is not an isolated issue of the WAR plugin - that can happen whenever
> you make a project change and don't call clean (like, say, removing a
> resources). I don't think the plugin should be responsible for that.
>
> Am I missing something obvious here? Also, we have several use cases
> > where copying the libraries as ${artifactId}.${type} (e.g. without the
> > version and/or the classifier) would be handy.
> >
> > The assembly plugin already provides this so:
> >
> > 1. What do you think about having this feature in WAR/EAR?
>
>
> +1 on adding an "outputFileNameMapping".

See MWAR-93.

Cheers,
Stéphane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Mapping strategy for libraries in the WAR/EAR plugin

[Eric Redmond <er...@gmail.com>]

On 3/7/07, Stephane Nicoll <st...@gmail.com> wrote:
>
> Hi,
>
> I am starting using the WAR plugin extensively as a user this time and
> I'd like your insight about the addition of a mapping strategy in the
> WAR/EAR plugin.
>
> The worst case I can see is when you have SNAPSHOT dependencies and
> you download a new SNAPSHOT without calling mvn clean. Since Maven
> will copy the library with the "full name" (i.e. with the build
> number), you end up with *two* versions of the library in your
> WEB-INF/lib.


This is not an isolated issue of the WAR plugin - that can happen whenever
you make a project change and don't call clean (like, say, removing a
resources). I don't think the plugin should be responsible for that.

Am I missing something obvious here? Also, we have several use cases
> where copying the libraries as ${artifactId}.${type} (e.g. without the
> version and/or the classifier) would be handy.
>
> The assembly plugin already provides this so:
>
> 1. What do you think about having this feature in WAR/EAR?


+1 on adding an "outputFileNameMapping".

2. Is the mapping thingy in the assembly plugin can be reused? (by
> putting it to shared or something)
>
> Thanks,
> Stéphane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond