Maven Resources Plugin
  1. Maven Resources Plugin
  2. MRESOURCES-77

Filters for copy-resources goal in plugin configuration section are ignored

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.4
    • Component/s: None
    • Labels:
      None

      Description

      I need to have a project where I can create multiple versions of resource files using different filters, I am trying to use the copy-resources goal for this purpose by making it part of the generate-resource phase and specifying the filters and resources under the plugin section of the POM.

      <plugins>
      	<plugin>
      		<artifactId>maven-resources-plugin</artifactId>
      		<executions>
      			<execution>
      				<id>config-a</id>
      				<phase>generate-resources</phase>
      				<goals>
      					<goal>copy-resources</goal>
      				</goals>
      				<configuration>
      					<outputDirectory>
      						${basedir}/target/generated-resources/a
      					</outputDirectory>
      					<filters>
      						<filter>a.properties</filter>
      					</filters>
      					<resources>
      						<resource>
      							<directory>etc/build</directory>
      							<filtering>true</filtering>
      							<includes>
      								<include>jndi.properties</include>
      							</includes>
      						</resource>
      					</resources>
      				</configuration>
      			</execution>
      			<execution>
      				<id>config-b</id>
      				<phase>generate-resources</phase>
      				<goals>
      					<goal>copy-resources</goal>
      				</goals>
      				<configuration>
      					<outputDirectory>
      						${basedir}/target/generated-resources/b
      					</outputDirectory>
      					<filters>
      						<filter>b.properties</filter>
      					</filters>
      					<resources>
      						<resource>
      							<directory>etc/build</directory>
      							<filtering>true</filtering>
      							<includes>
      								<include>jndi.properties</include>
      							</includes>
      						</resource>
      					</resources>
      				</configuration>
      			</execution>
      		</executions>
      	</plugin>
      	<!-- Other plugin entries -->
      </plugins>

      After doing some debugging, the problem seems to be caused by a combination of things:

      • The CopyResourcesMojo doesn't define its own filters field, so it inherits the configuration from the ResourcesMojo. That configuration specifies that it uses $ {project.build.filters} by default. This is part of the plugin.xml in the repository as
        <filters implementation="java.util.List">${project.build.filters}

        </filters>

      • When the merging of the plugin.xml configuration from the repository with the configuration from the POM is done, it includes the filters that were specified in the POM, but also includes the default value and implementation attribute. Hence, when the plugin fields are populated (in DefaultPluginManager.populatePluginFields), it gets the value $ {project.build.filters} instead of using the <filter> children from the POM configuration.

        I am not really sure what could be a good solution. Removing the default of ${project.build.filters}

        for the CopyResourcesMojo would make this scenario work, but it would make the filters required when the plugin is declared in the plugins section.

      1. filter-test.zip
        1 kB
        Lars Beuster
      2. MRESOURCES-77.patch
        12 kB
        Peter Janes
      3. MRESOURCES-77.patch
        2 kB
        Fabian Bauschulte

        Activity

        Daniel Uribe created issue -
        Hide
        Olivier Lamy (*$^¨%`£) added a comment -

        Can you provide a project test case ?
        Thanks

        Show
        Olivier Lamy (*$^¨%`£) added a comment - Can you provide a project test case ? Thanks
        Hide
        Lars Beuster added a comment -

        I have the same problem: nested filter elements are ignored by copy-resources.

        A test-project comes as an attachment.

        Thanks
        Lars

        Show
        Lars Beuster added a comment - I have the same problem: nested filter elements are ignored by copy-resources. A test-project comes as an attachment. Thanks Lars
        Lars Beuster made changes -
        Field Original Value New Value
        Attachment filter-test.zip [ 38572 ]
        Hide
        David Matějček added a comment -

        This is blocker issue for me

        Show
        David Matějček added a comment - This is blocker issue for me
        Fabian Bauschulte made changes -
        Attachment MRESOURCES-77.patch [ 41183 ]
        Hide
        Peter Janes added a comment -

        This is a new patch (with test cases, basically combining the configurations from src/it/filter and src/it/copy-resources-it) that doesn't remove the default filters in ResourcesMojo. Any locally-configured filters will replace the POM's filters, otherwise they'll be inherited.

        Show
        Peter Janes added a comment - This is a new patch (with test cases, basically combining the configurations from src/it/filter and src/it/copy-resources-it) that doesn't remove the default filters in ResourcesMojo. Any locally-configured filters will replace the POM's filters, otherwise they'll be inherited.
        Peter Janes made changes -
        Attachment MRESOURCES-77.patch [ 42492 ]
        Hide
        John Casey added a comment -

        Review for 2.4 release.

        Show
        John Casey added a comment - Review for 2.4 release.
        John Casey made changes -
        Fix Version/s 2.4 [ 14554 ]
        John Casey made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Assignee John Casey [ jdcasey ]
        Hervé Boutemy made changes -
        Description I need to have a project where I can create multiple versions of resource files using different filters, I am trying to use the copy-resources goal for this purpose by making it part of the generate-resource phase and specifying the filters and resources under the plugin section of the POM.

        <plugins>
        <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
        <execution>
        <id>config-a</id>
        <phase>generate-resources</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
        <configuration>
        <outputDirectory>
        ${basedir}/target/generated-resources/a
        </outputDirectory>
        <filters>
        <filter>a.properties</filter>
        </filters>
        <resources>
        <resource>
        <directory>etc/build</directory>
        <filtering>true</filtering>
        <includes>
        <include>jndi.properties</include>
        </includes>
        </resource>
        </resources>
        </configuration>
        </execution>
        <execution>
        <id>config-b</id>
        <phase>generate-resources</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
        <configuration>
        <outputDirectory>
        ${basedir}/target/generated-resources/b
        </outputDirectory>
        <filters>
        <filter>b.properties</filter>
        </filters>
        <resources>
        <resource>
        <directory>etc/build</directory>
        <filtering>true</filtering>
        <includes>
        <include>jndi.properties</include>
        </includes>
        </resource>
        </resources>
        </configuration>
        </execution>
        </executions>
        </plugin>
        <!-- Other plugin entries -->
        </plugins>

        After doing some debugging, the problem seems to be caused by a combination of things:

        - The CopyResourcesMojo doesn't define its own filters field, so it inherits the configuration from the ResourcesMojo. That configuration specifies that it uses ${project.build.filters} by default. This is part of the plugin.xml in the repository as
              <filters implementation="java.util.List">${project.build.filters}</filters>
        - When the merging of the plugin.xml configuration from the repository with the configuration from the POM is done, it includes the filters that were specified in the POM, but also includes the default value and implementation attribute. Hence, when the plugin fields are populated (in DefaultPluginManager.populatePluginFields), it gets the value ${project.build.filters} instead of using the <filter> children from the POM configuration.

        I am not really sure what could be a good solution. Removing the default of ${project.build.filters} for the CopyResourcesMojo would make this scenario work, but it would make the filters required when the plugin is declared in the plugins section.
        I need to have a project where I can create multiple versions of resource files using different filters, I am trying to use the copy-resources goal for this purpose by making it part of the generate-resource phase and specifying the filters and resources under the plugin section of the POM.

        {code:xml}<plugins>
        <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
        <execution>
        <id>config-a</id>
        <phase>generate-resources</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
        <configuration>
        <outputDirectory>
        ${basedir}/target/generated-resources/a
        </outputDirectory>
        <filters>
        <filter>a.properties</filter>
        </filters>
        <resources>
        <resource>
        <directory>etc/build</directory>
        <filtering>true</filtering>
        <includes>
        <include>jndi.properties</include>
        </includes>
        </resource>
        </resources>
        </configuration>
        </execution>
        <execution>
        <id>config-b</id>
        <phase>generate-resources</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
        <configuration>
        <outputDirectory>
        ${basedir}/target/generated-resources/b
        </outputDirectory>
        <filters>
        <filter>b.properties</filter>
        </filters>
        <resources>
        <resource>
        <directory>etc/build</directory>
        <filtering>true</filtering>
        <includes>
        <include>jndi.properties</include>
        </includes>
        </resource>
        </resources>
        </configuration>
        </execution>
        </executions>
        </plugin>
        <!-- Other plugin entries -->
        </plugins>{code}

        After doing some debugging, the problem seems to be caused by a combination of things:

        - The CopyResourcesMojo doesn't define its own filters field, so it inherits the configuration from the ResourcesMojo. That configuration specifies that it uses ${project.build.filters} by default. This is part of the plugin.xml in the repository as
              <filters implementation="java.util.List">${project.build.filters}</filters>
        - When the merging of the plugin.xml configuration from the repository with the configuration from the POM is done, it includes the filters that were specified in the POM, but also includes the default value and implementation attribute. Hence, when the plugin fields are populated (in DefaultPluginManager.populatePluginFields), it gets the value ${project.build.filters} instead of using the <filter> children from the POM configuration.

        I am not really sure what could be a good solution. Removing the default of ${project.build.filters} for the CopyResourcesMojo would make this scenario work, but it would make the filters required when the plugin is declared in the plugins section.
        Mark Thomas made changes -
        Project Import Sun Apr 05 12:20:57 UTC 2015 [ 1428236457206 ]
        Mark Thomas made changes -
        Workflow jira [ 12724904 ] Default workflow, editable Closed status [ 12756735 ]
        Mark Thomas made changes -
        Project Import Mon Apr 06 01:00:00 UTC 2015 [ 1428282000487 ]
        Mark Thomas made changes -
        Workflow jira [ 12962689 ] Default workflow, editable Closed status [ 12999139 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        286d 7h 57m 1 John Casey 20/Aug/09 19:37

          People

          • Assignee:
            John Casey
            Reporter:
            Daniel Uribe
          • Votes:
            5 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development