[
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
