Maven WAR Plugin
  1. Maven WAR Plugin
  2. MWAR-96

WebResource not filtered with system properties.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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

      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.

      1. patch-CompositeMapa.txt
        1 kB
        KlaasJan Elzinga
      2. patch-junit-test.txt
        1 kB
        KlaasJan Elzinga

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          304d 14h 58m 1 Olivier Lamy (*$^¨%`£) 01/Feb/08 16:24
          Mark Thomas made changes -
          Workflow jira [ 12966444 ] Default workflow, editable Closed status [ 13002759 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 01:49:55 UTC 2015 [ 1428284995525 ]
          Mark Thomas made changes -
          Workflow jira [ 12728512 ] Default workflow, editable Closed status [ 12764949 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 13:28:45 UTC 2015 [ 1428240525159 ]
          Hervé Boutemy made changes -
          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.
          When filtering a resource:
          {code:xml} <webResources>
                      <resource>
                        <directory>${basedir}/src/main/resources/</directory>
                        <filtering>true</filtering>
                        <includes>
                           <include>index.jsp</include>
                        </includes>
                      </resource>
                    </webResources>{code}

          The index.jsp contains:
          {code:xml} <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>{code}

          After mvn clean install the filtered index.jsp looks like:
          {code:xml} <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>{code}

          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.
          Olivier Lamy (*$^¨%`£) made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Olivier Lamy [ olamy ]
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          fixed in rev 617677. Now the plugin use the maven-filtering component.

          Show
          Olivier Lamy (*$^¨%`£) added a comment - fixed in rev 617677. Now the plugin use the maven-filtering component.
          Olivier Lamy (*$^¨%`£) made changes -
          Link This issue depends upon MNG-3374 [ MNG-3374 ]
          Olivier Lamy (*$^¨%`£) made changes -
          Fix Version/s 2.1-alpha-2 [ 13804 ]
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          We must have a common place for this CompositeMap job because the same code it's used/duplicate in some place : resources plugin assembly plugin.
          WDYT about maven-collections in shared ?

          Show
          Olivier Lamy (*$^¨%`£) added a comment - We must have a common place for this CompositeMap job because the same code it's used/duplicate in some place : resources plugin assembly plugin. WDYT about maven-collections in shared ?
          KlaasJan Elzinga made changes -
          Attachment patch-CompositeMapa.txt [ 26621 ]
          Hide
          KlaasJan Elzinga added a comment -

          Attached fix. I'm not sure if the original preferences regarding the dominant and the recessive are still there. With the patch applied the recessive Map gains preference if a conflict in propertynames is signalled. A better solution is probably to enhance the call to ReflectionValueExtractor in the dominant Map.

          Show
          KlaasJan Elzinga added a comment - Attached fix. I'm not sure if the original preferences regarding the dominant and the recessive are still there. With the patch applied the recessive Map gains preference if a conflict in propertynames is signalled. A better solution is probably to enhance the call to ReflectionValueExtractor in the dominant Map.
          KlaasJan Elzinga made changes -
          Field Original Value New Value
          Attachment patch-junit-test.txt [ 26613 ]
          Hide
          KlaasJan Elzinga added a comment -

          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.

          Show
          KlaasJan Elzinga added a comment - 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.
          KlaasJan Elzinga created issue -

            People

            • Assignee:
              Olivier Lamy (*$^¨%`£)
              Reporter:
              KlaasJan Elzinga
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development