You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Piotr Tabor (JIRA)" <ji...@codehaus.org> on 2007/04/06 20:39:05 UTC
[jira] Created: (MWAR-97) War plugin and Overlays handling
War plugin and Overlays handling
--------------------------------
Key: MWAR-97
URL: http://jira.codehaus.org/browse/MWAR-97
Project: Maven 2.x War Plugin
Issue Type: New Feature
Affects Versions: 2.0.2, 2.0.1, 2.0, 2.0.3
Reporter: Piotr Tabor
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92768 ]
Stephane Nicoll commented on MWAR-97:
-------------------------------------
patch applied in branch:
http://svn.apache.org/repos/asf/maven/plugins/branches/MWAR-97/
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94153 ]
Stephane Nicoll commented on MWAR-97:
-------------------------------------
Sounds good except the overlay thingy. Instead of a method that will realize the whole overlay I would have one task per overlay. Once we have this, we put all tasks in a ordered list according to, namely, the <overlays> configuration tag. And the only thing is to have a manager that will execute the tasks. We also need some sort of context object to pass information from one task to the other.
A base AbstractTask could have common methods (copyFile, unpack, filtering, etc)
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on MWAR-97 started by Stephane Nicoll.
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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 first.
> The behavior should be deterministic so the copy will happen not
> matter how if a file is newer than the one being applied. Overlays
> use a first win strategy.
> 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 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll closed MWAR-97.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.1-alpha-1
This is done and applied in trunk.
Staging site available: http://people.apache.org/~snicoll/maven-stage-repo/
2.1-alpha-1 available in the maven snapshot repository.
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1-alpha-1
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-1
>
> Attachments: MWAR-97.diff
>
>
> 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 first.
> The behavior should be deterministic so the copy will happen not
> matter how if a file is newer than the one being applied. Overlays
> use a first win strategy.
> 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 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102411 ]
Stephane Nicoll commented on MWAR-97:
-------------------------------------
just for the record, I need to implement a caching system with relativeFilePath + overlayId to avoid writing the files every now and then. (serialization with XStream sounds good and is easy).
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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 first.
> The behavior should be deterministic so the copy will happen not
> matter how if a file is newer than the one being applied. Overlays
> use a first win strategy.
> 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 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93804 ]
Stephane Nicoll commented on MWAR-97:
-------------------------------------
Piotr,
I added some nice helpers to test the overlay functionality. I have written 3 very simple tests but they tests quite everything (content of the webapp, text file content, content completeness that is it tests that only the specified files are there). It would be nice if we could port all your tests to this technique (see WarOverlaysTest, note that the wars are generated automatically from the content of src/test/resources/overlays/XXX).
I had a look to the code, I'd like to separate the logic in a manager. AbstractWarMojo contains way too much code. What about a WarTask just like in the assembly plugin (one task to handle an overlay, one task to copy the web resources, one task to copy the src/main/webapp content, etc).
Are you going to work on it short term ?
Let me know.
Thanks!
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-97) War plugin and Overlays handling
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll updated MWAR-97:
--------------------------------
Description:
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 first.
The behavior should be deterministic so the copy will happen not
matter how if a file is newer than the one being applied. Overlays
use a first win strategy.
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 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
was:
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
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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 first.
> The behavior should be deterministic so the copy will happen not
> matter how if a file is newer than the one being applied. Overlays
> use a first win strategy.
> 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 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-97) War plugin and Overlays handling
Posted by "Piotr Tabor (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94149 ]
Piotr Tabor commented on MWAR-97:
---------------------------------
So I think there are need for such tasks (assigned to "goals"):
Goals:
*war:exploded*
- GenerateClassesJarTask
- GenerateManifestTask
- CopyResourcesTask
- CopyDependenciesTaks
- RealizeOverlaysTask
*war:inplace*
- GenerateClassesJarTask
- GenerateManifestTask
- CopyResourcesTask
- CopyDependenciesTask
- RealizeOverlaysTask
*war:war*
- GenerateClassesJarTask
- GenerateManifestTask
- CopyResourcesTask
- CopyDependenciesTaks
- RealizeOverlaysTask
- ArchiveWarTask
*war:manifest*
- GenerateManifestTask
I think that every task should have constructor with one parameter that will AbstractWarMojo provide
from do Mojo all important informations and some "busines" methods.
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Assignee: Stephane Nicoll
> Attachments: MWAR-97.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-97) War plugin and Overlays handling
Posted by "Piotr Tabor (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Piotr Tabor updated MWAR-97:
----------------------------
Attachment: MWAR-97.diff
I attached complete implementation with tests.
The only problem with testExplodedWarMergeWarUpdated(org.apache.maven.plugin.war.WarExplodedMojoTest
(connected with a copyFileIfModified method) needs some discuss.
> War plugin and Overlays handling
> --------------------------------
>
> Key: MWAR-97
> URL: http://jira.codehaus.org/browse/MWAR-97
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
> Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
> Reporter: Piotr Tabor
> Attachments: MWAR-97.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira