Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-1995

filtering element in pom.xml ignore properties

    Details

    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      <jvanzyl> you can mention it0091 as the test case
      The following pom.xml does not end up filtering the resources:

      <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

      <modelVersion>4.0.0</modelVersion>
      <groupId>org.objectweb.celtix</groupId>
      <artifactId>test</artifactId>
      <packaging>jar</packaging>
      <version>1.0</version>
      <name>Test</name>

      <properties>
      <filter.resources>true</filter.resources>
      </properties>

      <build>
      <resources>
      <resource>
      <directory>src/main/resources</directory>
      <includes>
      <include>**</include>
      </includes>
      <filtering>$

      {filter.resources}

      </filtering>
      </resource>
      </resources>
      </build>
      </project>

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          This will have to wait for Maven 2.1.

          The reason is that the filtering property in org.apache.maven.model.Resource is actually a boolean, not a String. This is correct from a pure perspective, but it compromises our ability to interpolate that value in the current project-loading process. The reason is that a given POM is first read into a org.apache.maven.model.Model intsance, /then/ interpolated, which means that the expression above:

          <resource><filtering>$

          {filter.resources}

          </filtering></resource>

          has already been parsed (by the XML-parsing part of the project-loading process) into the boolean value /false/.

          In order to change this, we'd need to do one of two things:

          1. Change the Resource.filtering property to a String, so that expressions would be preserved long enough to be interpolated by the current POM loading process.

          2. Change the POM loading process to read/interpolate all in one step, before a Model instance is created.

          #1 is not feasible for 2.0.x, since it would change a public API that many plugins depend on. #2 is more reasonable, but cannot happen in the 2.0.x line, due to the relative complexity involved with changing something so core to Maven itself.

          In fact, we already have some plans to change the POM loading process to make it more flexible, and hopefully resolve more of these sticky interpolation problems on the way.

          Show
          John Casey added a comment - This will have to wait for Maven 2.1. The reason is that the filtering property in org.apache.maven.model.Resource is actually a boolean, not a String. This is correct from a pure perspective, but it compromises our ability to interpolate that value in the current project-loading process. The reason is that a given POM is first read into a org.apache.maven.model.Model intsance, /then/ interpolated, which means that the expression above: <resource><filtering>$ {filter.resources} </filtering></resource> has already been parsed (by the XML-parsing part of the project-loading process) into the boolean value /false/. In order to change this, we'd need to do one of two things: 1. Change the Resource.filtering property to a String, so that expressions would be preserved long enough to be interpolated by the current POM loading process. 2. Change the POM loading process to read/interpolate all in one step, before a Model instance is created. #1 is not feasible for 2.0.x, since it would change a public API that many plugins depend on. #2 is more reasonable, but cannot happen in the 2.0.x line, due to the relative complexity involved with changing something so core to Maven itself. In fact, we already have some plans to change the POM loading process to make it more flexible, and hopefully resolve more of these sticky interpolation problems on the way.
          Hide
          Benjamin Bentmann added a comment -

          The corresponding it0091 is passing for me on trunk, so this seems to be resolved and could be closed by the responsible committer

          Show
          Benjamin Bentmann added a comment - The corresponding it0091 is passing for me on trunk, so this seems to be resolved and could be closed by the responsible committer
          Hide
          shane.isbell added a comment -

          Fixed.

          Show
          shane.isbell added a comment - Fixed.

            People

            • Assignee:
              Shane Isbell
              Reporter:
              Daniel Kulp
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: