Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Fix Version/s: 2.1-beta-1
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
When the filter option is enabled in the war plugin, the plugin searches in the affected files for the pattern @...@ and ${...}. If such a pattern is found, the plugin tries to replace the found value. Therefore the ReflectionValueExtractor is used which removes the first part before the dot of the given value; e.g. "node.version" becomes "version". Then the ReflectionValueExtractor tries to find a get- or is-method in the given object (a MavenProject object).
That means: if the 2nd part of the ${}-property can be found as getter in the MavenProject class, the plugin always uses the maven plugin values.
The value extractor should only remove the 1st part from the property if the property begins with "project.".
There is a similar bug report for the resource plugin (date june 2006!!!) which is not yet assigned (title: Filtering ${foo.file} evaluates to in full path to pom.xml).
Attachments
Issue Links
| This issue is duplicated by: | ||||
| MWAR-171 | External Web Resources are not properly filtered |
|
|
|
| This issue is related to: | ||||
| MSHARED-60 | Filtering ${foo.file} evaluates to in full path to pom.xml |
|
|
|
| MRESOURCES-20 | Filtering ${foo.file} evaluates to in full path to pom.xml |
|
|
|
| This issue depends upon: | ||||
| MSHARED-60 | Filtering ${foo.file} evaluates to in full path to pom.xml |
|
|
|
The resource bug is http://jira.codehaus.org/browse/MRESOURCES-20