Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Fix Version/s: 2.1-alpha-2
-
Component/s: None
-
Labels:None
-
Environment:java 5.0, Windows XP
-
Number of attachments :
Description
When filtering a resource:
<webResources> <resource> <directory>${basedir}/src/main/resources/</directory> <filtering>true</filtering> <includes> <include>index.jsp</include> </includes> </resource> </webResources>
The index.jsp contains:
<tr><td>java version</td><td>${java.version}</td></tr> <tr><td>Project</td><td>${pom.name}</td></tr> <tr><td>Version</td><td>${pom.version}</td></tr>
After mvn clean install the filtered index.jsp looks like:
<tr><td>java version</td><td>1.0.0.SNAPSHOT</td></tr> <tr><td>Project</td><td>FrieslandBank TMS TNS WebApp</td></tr> <tr><td>Version</td><td>1.0.0.SNAPSHOT</td></tr>
The value java.version is filtered to the version of the pom and not the system property. The same goes for os.name which is translated to pom.name.
Issue Links
- depends upon
-
MSHARED-46
Create a common component for files filtering
-
Patch for junit test (patch-junit-test.txt). It shows that the java.version is not filtered.
I investigated a little further and found the following:
CompositeMap uses a dominant map and a recessive map. The dominant map is the pom (basically). It uses reflection to locate for example java.version. This value is found in the project since the ReflectionExtractor is stripping any root comments (java. in this case). So for java.version the pom.version value is found.
I tried calling ReflectionValueExtractor with trimToken = false, but then no dominant values were found.