You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephane Nicoll <st...@gmail.com> on 2007/03/19 22:16:56 UTC
War plugin and Overlays handling
Hi,
Piotr and I are currently working on the war plugin and especially
this overlay mechanism that needs to be upgraded. Currently a couple
of issues [1] in the war plugin are linked to this functionality and
we should really address them.
The idea here is to provide a better way to handle overlays through an
explicit configuration. An overlay has the following parameters:
* groupId
* artifactId
* classifier (optionnal)
* includes (default includes everything)
* excludes (default META-INF)
The order in which overlays are specified defined the order in which
they are applied. An overlay without a groupId/artifactId is
considered as the current build. If no such overlay is defined, it is
applied *last*.
The behavior should be deterministic so the copy will happen not
matter how if a file is newer than the one being applied. Overlays
order always wins.
If no overlays section is defined, the wars are processed as before;
dependentWarIncludes and dependentWarExcludes are honored. If an
overlays section is defined and those configuration items are defined,
they are ignored and a warning is logged.
If a dependent war is missing in the overlays section, it's applied
after custom overlays *and* before the current build (if the current
build is not specified of course) with the default includes/excludes.
Does that sounds ok to you? If so I'll add the proposition to the war
site and start the implementation with Piotr. We're also thinking
about integrating the merge functionality of the cargo plugin but we
still need to discuss with the cargo guys if it will be feasible.
Please comment.
Stéphane
[1] MWAR-72, MWAR-66, MWAR-78
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: War plugin and Overlays handling
Posted by Stephane Nicoll <st...@gmail.com>.
WEB-INF/lib sorry.
Just back from vacation, hope ApacheCon was good. I've worked on it
during the week and I'll send a mail later, probably tomorrow.
Stéphane.
On 3/30/07, Andrew Williams <an...@handyande.co.uk> wrote:
>
> On 21 Mar 2007, at 07:04, Stephane Nicoll wrote:
>
> > Hi,
> >
> > On 3/21/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> >> Will the use of this new overlay cause the transitive dependencies
> >> of the overlayed wars to be resolved and included? I currently
> >> construct wars that I intend to be used as overlays by excluding
> >> all the jars. I do this to avoid conflicts but also to reduce the
> >> size in the repository. Unfortunately because I'm using a very old
> >> version of mwar, I have to manually keep my war project
> >> dependencies synchronized. If these transitive dependencies from
> >> the wars are automatically pulled in, then I think it's safe to
> >> also exclude WEB-INF/lib by default from the overlays. I think
> >> we'll have an excellent solution at that point.
> >
> > The proposition sticks to a simple overlay which does not resolve the
> > transitive dependencies, that's a very good point. We could even put a
> > default exclude on WEB-INF/* for overlays that are not the current
> > build (?). This will also solves the issues of people having multiple
> > time the same dep with a different minor versions in the resulting
> > war.
>
> Erm, does that not mean that all classes from other wars will be
> omitted?
>
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: War plugin and Overlays handling
Posted by Andrew Williams <an...@handyande.co.uk>.
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote:
> Hi,
>
> On 3/21/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>> Will the use of this new overlay cause the transitive dependencies
>> of the overlayed wars to be resolved and included? I currently
>> construct wars that I intend to be used as overlays by excluding
>> all the jars. I do this to avoid conflicts but also to reduce the
>> size in the repository. Unfortunately because I'm using a very old
>> version of mwar, I have to manually keep my war project
>> dependencies synchronized. If these transitive dependencies from
>> the wars are automatically pulled in, then I think it's safe to
>> also exclude WEB-INF/lib by default from the overlays. I think
>> we'll have an excellent solution at that point.
>
> The proposition sticks to a simple overlay which does not resolve the
> transitive dependencies, that's a very good point. We could even put a
> default exclude on WEB-INF/* for overlays that are not the current
> build (?). This will also solves the issues of people having multiple
> time the same dep with a different minor versions in the resulting
> war.
Erm, does that not mean that all classes from other wars will be
omitted?
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: War plugin and Overlays handling
Posted by Stephane Nicoll <st...@gmail.com>.
OK, good to hear, we'll have a look.
One of the very first step I would like to achieve is to share the
following functionalities:
* Ability to filter data *with* interpolation (just like what's inside
the resources plugin)
* Ability to unpack archives with includes/excludes filter *and* the
ability to filter the content
There's a couple of issues in various plugins (assembly, dependency,
war itself) for those things, it would make sense to share that.
Brian, John, could you please help for this?
Thanks,
Stéphane
On 3/21/07, mraible <ma...@raibledesigns.com> wrote:
>
> If you're looking for a solution to resolving transitive dependencies from
> WARs, you can use the maven-warpath-plugin. We (at the AppFuse project)
> would *love* to see the functionality from this plugin added to the
> maven-war-plugin.
>
> http://static.appfuse.org/plugins/maven-warpath-plugin/
>
> Matt
>
>
> Stephane Nicoll-2 wrote:
> >
> > Hi,
> >
> > On 3/21/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> >> Stephane, Piotr,
> >> Thanks for taking this on and putting together this proposal. As we
> >> discussed previously, I have significant issues with the current war
> >> plugin, so much that we have been stuck using a patched version of
> >> 2.0-beta-2 because anything newer breaks my build. I believe that your
> >> proposal solves nearly all my issues.
> >>
> >
> > Yeah that's the purpose.
> >
> >> Will the use of this new overlay cause the transitive dependencies of the
> >> overlayed wars to be resolved and included? I currently construct wars
> >> that I intend to be used as overlays by excluding all the jars. I do this
> >> to avoid conflicts but also to reduce the size in the repository.
> >> Unfortunately because I'm using a very old version of mwar, I have to
> >> manually keep my war project dependencies synchronized. If these
> >> transitive dependencies from the wars are automatically pulled in, then I
> >> think it's safe to also exclude WEB-INF/lib by default from the overlays.
> >> I think we'll have an excellent solution at that point.
> >
> > The proposition sticks to a simple overlay which does not resolve the
> > transitive dependencies, that's a very good point. We could even put a
> > default exclude on WEB-INF/* for overlays that are not the current
> > build (?). This will also solves the issues of people having multiple
> > time the same dep with a different minor versions in the resulting
> > war.
> >
> > Oh by the way, I forgot to tell that we could include multiple times
> > the same overlays if we want to control the overriding policy of a
> > particular piece of an overlay.
> >
> > The only thing I am afraid of right now is performance. Not sure we
> > will be able to implement this without copying stuff more than one
> > time to the target directory.
> >
> >>
> >> Thanks,
> >>
> > Thanks for taking the time to respond. We will start the
> > implementation, probably targetting 2.1 instead of 2.0.3 since it's
> > quite a major new functionality.
> >
> > Any other comment is more than welcome (such as sample projects that
> > reproduces complex scenario that we could include in ITs).
> >
> > Thanks,
> > Stéphane
> >
> >
> >> -----Original Message-----
> >> From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com]
> >> Sent: Monday, March 19, 2007 5:17 PM
> >> To: Maven Developers List
> >> Cc: Piotr Tabor
> >> Subject: War plugin and Overlays handling
> >>
> >> Hi,
> >>
> >> Piotr and I are currently working on the war plugin and especially
> >> this overlay mechanism that needs to be upgraded. Currently a couple
> >> of issues [1] in the war plugin are linked to this functionality and
> >> we should really address them.
> >>
> >> The idea here is to provide a better way to handle overlays through an
> >> explicit configuration. An overlay has the following parameters:
> >>
> >> * groupId
> >> * artifactId
> >> * classifier (optionnal)
> >> * includes (default includes everything)
> >> * excludes (default META-INF)
> >>
> >> The order in which overlays are specified defined the order in which
> >> they are applied. An overlay without a groupId/artifactId is
> >> considered as the current build. If no such overlay is defined, it is
> >> applied *last*.
> >>
> >> The behavior should be deterministic so the copy will happen not
> >> matter how if a file is newer than the one being applied. Overlays
> >> order always wins.
> >>
> >> If no overlays section is defined, the wars are processed as before;
> >> dependentWarIncludes and dependentWarExcludes are honored. If an
> >> overlays section is defined and those configuration items are defined,
> >> they are ignored and a warning is logged.
> >>
> >> If a dependent war is missing in the overlays section, it's applied
> >> after custom overlays *and* before the current build (if the current
> >> build is not specified of course) with the default includes/excludes.
> >>
> >> Does that sounds ok to you? If so I'll add the proposition to the war
> >> site and start the implementation with Piotr. We're also thinking
> >> about integrating the merge functionality of the cargo plugin but we
> >> still need to discuss with the cargo guys if it will be feasible.
> >>
> >> Please comment.
> >>
> >> Stéphane
> >>
> >> [1] MWAR-72, MWAR-66, MWAR-78
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/War-plugin-and-Overlays-handling-tf3429803s177.html#a9602182
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: War plugin and Overlays handling
Posted by mraible <ma...@raibledesigns.com>.
If you're looking for a solution to resolving transitive dependencies from
WARs, you can use the maven-warpath-plugin. We (at the AppFuse project)
would *love* to see the functionality from this plugin added to the
maven-war-plugin.
http://static.appfuse.org/plugins/maven-warpath-plugin/
Matt
Stephane Nicoll-2 wrote:
>
> Hi,
>
> On 3/21/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>> Stephane, Piotr,
>> Thanks for taking this on and putting together this proposal. As we
>> discussed previously, I have significant issues with the current war
>> plugin, so much that we have been stuck using a patched version of
>> 2.0-beta-2 because anything newer breaks my build. I believe that your
>> proposal solves nearly all my issues.
>>
>
> Yeah that's the purpose.
>
>> Will the use of this new overlay cause the transitive dependencies of the
>> overlayed wars to be resolved and included? I currently construct wars
>> that I intend to be used as overlays by excluding all the jars. I do this
>> to avoid conflicts but also to reduce the size in the repository.
>> Unfortunately because I'm using a very old version of mwar, I have to
>> manually keep my war project dependencies synchronized. If these
>> transitive dependencies from the wars are automatically pulled in, then I
>> think it's safe to also exclude WEB-INF/lib by default from the overlays.
>> I think we'll have an excellent solution at that point.
>
> The proposition sticks to a simple overlay which does not resolve the
> transitive dependencies, that's a very good point. We could even put a
> default exclude on WEB-INF/* for overlays that are not the current
> build (?). This will also solves the issues of people having multiple
> time the same dep with a different minor versions in the resulting
> war.
>
> Oh by the way, I forgot to tell that we could include multiple times
> the same overlays if we want to control the overriding policy of a
> particular piece of an overlay.
>
> The only thing I am afraid of right now is performance. Not sure we
> will be able to implement this without copying stuff more than one
> time to the target directory.
>
>>
>> Thanks,
>>
> Thanks for taking the time to respond. We will start the
> implementation, probably targetting 2.1 instead of 2.0.3 since it's
> quite a major new functionality.
>
> Any other comment is more than welcome (such as sample projects that
> reproduces complex scenario that we could include in ITs).
>
> Thanks,
> Stéphane
>
>
>> -----Original Message-----
>> From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com]
>> Sent: Monday, March 19, 2007 5:17 PM
>> To: Maven Developers List
>> Cc: Piotr Tabor
>> Subject: War plugin and Overlays handling
>>
>> Hi,
>>
>> Piotr and I are currently working on the war plugin and especially
>> this overlay mechanism that needs to be upgraded. Currently a couple
>> of issues [1] in the war plugin are linked to this functionality and
>> we should really address them.
>>
>> The idea here is to provide a better way to handle overlays through an
>> explicit configuration. An overlay has the following parameters:
>>
>> * groupId
>> * artifactId
>> * classifier (optionnal)
>> * includes (default includes everything)
>> * excludes (default META-INF)
>>
>> The order in which overlays are specified defined the order in which
>> they are applied. An overlay without a groupId/artifactId is
>> considered as the current build. If no such overlay is defined, it is
>> applied *last*.
>>
>> The behavior should be deterministic so the copy will happen not
>> matter how if a file is newer than the one being applied. Overlays
>> order always wins.
>>
>> If no overlays section is defined, the wars are processed as before;
>> dependentWarIncludes and dependentWarExcludes are honored. If an
>> overlays section is defined and those configuration items are defined,
>> they are ignored and a warning is logged.
>>
>> If a dependent war is missing in the overlays section, it's applied
>> after custom overlays *and* before the current build (if the current
>> build is not specified of course) with the default includes/excludes.
>>
>> Does that sounds ok to you? If so I'll add the proposition to the war
>> site and start the implementation with Piotr. We're also thinking
>> about integrating the merge functionality of the cargo plugin but we
>> still need to discuss with the cargo guys if it will be feasible.
>>
>> Please comment.
>>
>> Stéphane
>>
>> [1] MWAR-72, MWAR-66, MWAR-78
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/War-plugin-and-Overlays-handling-tf3429803s177.html#a9602182
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: War plugin and Overlays handling
Posted by Stephane Nicoll <st...@gmail.com>.
Hi,
On 3/21/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Stephane, Piotr,
> Thanks for taking this on and putting together this proposal. As we discussed previously, I have significant issues with the current war plugin, so much that we have been stuck using a patched version of 2.0-beta-2 because anything newer breaks my build. I believe that your proposal solves nearly all my issues.
>
Yeah that's the purpose.
> Will the use of this new overlay cause the transitive dependencies of the overlayed wars to be resolved and included? I currently construct wars that I intend to be used as overlays by excluding all the jars. I do this to avoid conflicts but also to reduce the size in the repository. Unfortunately because I'm using a very old version of mwar, I have to manually keep my war project dependencies synchronized. If these transitive dependencies from the wars are automatically pulled in, then I think it's safe to also exclude WEB-INF/lib by default from the overlays. I think we'll have an excellent solution at that point.
The proposition sticks to a simple overlay which does not resolve the
transitive dependencies, that's a very good point. We could even put a
default exclude on WEB-INF/* for overlays that are not the current
build (?). This will also solves the issues of people having multiple
time the same dep with a different minor versions in the resulting
war.
Oh by the way, I forgot to tell that we could include multiple times
the same overlays if we want to control the overriding policy of a
particular piece of an overlay.
The only thing I am afraid of right now is performance. Not sure we
will be able to implement this without copying stuff more than one
time to the target directory.
>
> Thanks,
>
Thanks for taking the time to respond. We will start the
implementation, probably targetting 2.1 instead of 2.0.3 since it's
quite a major new functionality.
Any other comment is more than welcome (such as sample projects that
reproduces complex scenario that we could include in ITs).
Thanks,
Stéphane
> -----Original Message-----
> From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com]
> Sent: Monday, March 19, 2007 5:17 PM
> To: Maven Developers List
> Cc: Piotr Tabor
> Subject: War plugin and Overlays handling
>
> Hi,
>
> Piotr and I are currently working on the war plugin and especially
> this overlay mechanism that needs to be upgraded. Currently a couple
> of issues [1] in the war plugin are linked to this functionality and
> we should really address them.
>
> The idea here is to provide a better way to handle overlays through an
> explicit configuration. An overlay has the following parameters:
>
> * groupId
> * artifactId
> * classifier (optionnal)
> * includes (default includes everything)
> * excludes (default META-INF)
>
> The order in which overlays are specified defined the order in which
> they are applied. An overlay without a groupId/artifactId is
> considered as the current build. If no such overlay is defined, it is
> applied *last*.
>
> The behavior should be deterministic so the copy will happen not
> matter how if a file is newer than the one being applied. Overlays
> order always wins.
>
> If no overlays section is defined, the wars are processed as before;
> dependentWarIncludes and dependentWarExcludes are honored. If an
> overlays section is defined and those configuration items are defined,
> they are ignored and a warning is logged.
>
> If a dependent war is missing in the overlays section, it's applied
> after custom overlays *and* before the current build (if the current
> build is not specified of course) with the default includes/excludes.
>
> Does that sounds ok to you? If so I'll add the proposition to the war
> site and start the implementation with Piotr. We're also thinking
> about integrating the merge functionality of the cargo plugin but we
> still need to discuss with the cargo guys if it will be feasible.
>
> Please comment.
>
> Stéphane
>
> [1] MWAR-72, MWAR-66, MWAR-78
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: War plugin and Overlays handling
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Stephane, Piotr,
Thanks for taking this on and putting together this proposal. As we discussed previously, I have significant issues with the current war plugin, so much that we have been stuck using a patched version of 2.0-beta-2 because anything newer breaks my build. I believe that your proposal solves nearly all my issues.
Will the use of this new overlay cause the transitive dependencies of the overlayed wars to be resolved and included? I currently construct wars that I intend to be used as overlays by excluding all the jars. I do this to avoid conflicts but also to reduce the size in the repository. Unfortunately because I'm using a very old version of mwar, I have to manually keep my war project dependencies synchronized. If these transitive dependencies from the wars are automatically pulled in, then I think it's safe to also exclude WEB-INF/lib by default from the overlays. I think we'll have an excellent solution at that point.
Thanks,
-----Original Message-----
From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com]
Sent: Monday, March 19, 2007 5:17 PM
To: Maven Developers List
Cc: Piotr Tabor
Subject: War plugin and Overlays handling
Hi,
Piotr and I are currently working on the war plugin and especially
this overlay mechanism that needs to be upgraded. Currently a couple
of issues [1] in the war plugin are linked to this functionality and
we should really address them.
The idea here is to provide a better way to handle overlays through an
explicit configuration. An overlay has the following parameters:
* groupId
* artifactId
* classifier (optionnal)
* includes (default includes everything)
* excludes (default META-INF)
The order in which overlays are specified defined the order in which
they are applied. An overlay without a groupId/artifactId is
considered as the current build. If no such overlay is defined, it is
applied *last*.
The behavior should be deterministic so the copy will happen not
matter how if a file is newer than the one being applied. Overlays
order always wins.
If no overlays section is defined, the wars are processed as before;
dependentWarIncludes and dependentWarExcludes are honored. If an
overlays section is defined and those configuration items are defined,
they are ignored and a warning is logged.
If a dependent war is missing in the overlays section, it's applied
after custom overlays *and* before the current build (if the current
build is not specified of course) with the default includes/excludes.
Does that sounds ok to you? If so I'll add the proposition to the war
site and start the implementation with Piotr. We're also thinking
about integrating the merge functionality of the cargo plugin but we
still need to discuss with the cargo guys if it will be feasible.
Please comment.
Stéphane
[1] MWAR-72, MWAR-66, MWAR-78
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org