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

maven-resources-plugin ignores configuration/resources property (add a new mojo to copy resources)

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1, 2.2
    • Fix Version/s: 2.3
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      3

      Description

      I am evaluating maven + eclipse combo. In a trivial POM filtered resources exist only in target/classes. If one executes Project -> Clean under eclipse this information is lost. If filtered resources would appear as source folder they would survive cleaning and not got overriden by unfiltered ones.

      I have been trying to implement a scenario which would allow filtered resources to appear as "static" source folder under eclipse.
      The POM explains it best:

      <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>com.mobilebox.squash.client</groupId>
        <artifactId>squash-client</artifactId>
        <packaging>jar</packaging>
        <version>1.0-SNAPSHOT</version>
        <name>Maven Quick Start Archetype</name>
        <url>http://maven.apache.org</url>
        <build>
          <plugins>
            <plugin>
              <artifactId>maven-resources-plugin</artifactId>
              <executions>
                <execution>
                  <id>prefilter-resources</id>
                  <phase>generate-resources</phase>
                  <goals>
                    <goal>resources</goal>
                  </goals>
                  <configuration>
                    <outputDirectory>target/generated-resources</outputDirectory>
                    <resources>
                      <resource>
                        <directory>src/main/resource-templates</directory>
                        <filtering>true</filtering>
                      </resource>
                    </resources>
                  </configuration>
                </execution>
              </executions>
            </plugin>
          </plugins>
          <filters>
            <filter>${ffile}</filter>
          </filters>
          <resources>
            <resource>
              <directory>src/main/resources</directory>
            </resource>
            <resource>
              <directory>target/generated-resources</directory>
            </resource>
          </resources>
        </build>
        <dependencies>
          <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
          </dependency>
        </dependencies>
        <properties>
          <ffile>filter.properties</ffile>
        </properties>
      </project>
      

      thing is this part:

      <resources>
        <resource>
          <directory>src/main/properties</directory>
          <filtering>true</filtering>
        </resource>
      </resources>
      

      is completely ignored. Instead for both maven-resource-plugin executions (the one in generate-resources phase and the default one) this config is used:

      <resources>
        <resource>
          <directory>src/main/resources</directory>
        </resource>
        <resource>
          <directory>target/generated-resources</directory>
        </resource>
      </resources>
      

      which of course breaks the whole idea.

      Is this a bug or a design decision. In latter case is there any equivalent approach I might take?

        Issue Links

          Activity

          Hide
          Leszek Gawron added a comment -

          I have attached the relevant POM with correct indentation

          Show
          Leszek Gawron added a comment - I have attached the relevant POM with correct indentation
          Hide
          Chris Hagmann added a comment -

          I created a patch with a workaround. Apply the patch and create your own version of the plugin.

          Show
          Chris Hagmann added a comment - I created a patch with a workaround. Apply the patch and create your own version of the plugin.
          Hide
          Leszek Gawron added a comment -

          Thank you. It works like a charm. Will this patch get eventually into official sources?

          Show
          Leszek Gawron added a comment - Thank you. It works like a charm. Will this patch get eventually into official sources?
          Hide
          Brett Porter added a comment -

          the configuration is not the place to do this.

          If I understand correctly, you want to have filtered resources copied to a different location. That is what targetPath is for:

          <resource>
          <directory>src/main/properties</directory>
          <filtering>true</filtering>
          <targetPath>some/path/under/target/classes</targetPath>
          </resource>

          Show
          Brett Porter added a comment - the configuration is not the place to do this. If I understand correctly, you want to have filtered resources copied to a different location. That is what targetPath is for: <resource> <directory>src/main/properties</directory> <filtering>true</filtering> <targetPath>some/path/under/target/classes</targetPath> </resource>
          Hide
          Leszek Gawron added a comment -

          Brett unfortunatelly you don't. I need to use maven-resources-plugin in generate-resources phase. I do not want src/main/properties as a resource because eclipse would copy unfiltered resources (with @TAGS@) to target/classes. That prevents me from running test cases from under eclipse.

          So I just want to process src/main/properties into target/generated-resources (which I make a resource). This way eclipse never deals only with postprocessed resources.

          You're right it does not make much sense to use configuration/resources in process-resources phase. Still it is useful for former phases.

          Is that explanation enough to drop 'won't fix' ?

          Show
          Leszek Gawron added a comment - Brett unfortunatelly you don't. I need to use maven-resources-plugin in generate-resources phase. I do not want src/main/properties as a resource because eclipse would copy unfiltered resources (with @TAGS@) to target/classes. That prevents me from running test cases from under eclipse. So I just want to process src/main/properties into target/generated-resources (which I make a resource). This way eclipse never deals only with postprocessed resources. You're right it does not make much sense to use configuration/resources in process-resources phase. Still it is useful for former phases. Is that explanation enough to drop 'won't fix' ?
          Hide
          Brett Porter added a comment -

          ok, we should probably add a new mojo for copying files that will not be packaged.

          Show
          Brett Porter added a comment - ok, we should probably add a new mojo for copying files that will not be packaged.
          Hide
          Leszek Gawron added a comment -

          Example

          Show
          Leszek Gawron added a comment - Example
          Hide
          Leszek Gawron added a comment -

          My discussion on irc with Kenney ended up with the conclusion that something is wrong in plexus configurator because maven-resources-plugin mojo 'resources' field cannot be set from configuration (although it is not read-only). Thus the patch provided is only a workaround.

          Show
          Leszek Gawron added a comment - My discussion on irc with Kenney ended up with the conclusion that something is wrong in plexus configurator because maven-resources-plugin mojo 'resources' field cannot be set from configuration (although it is not read-only). Thus the patch provided is only a workaround.
          Hide
          Brett Porter added a comment -

          I guess the expression wins if not null.

          Show
          Brett Porter added a comment - I guess the expression wins if not null.
          Hide
          Dan Allen added a comment -

          I must chime in here because the root cause of this issue report has caused me extreme headaches. In my mind, and everyone sitting around me on the CM team, this is a MAJOR oversight in the resources plugin. Regardless of how it is fixed, it really just needs to be fixed (to get it out there) and then refactored. I will explain my use case and prove how badly we need this patch to go in (otherwise we will forever maintain our own version of this plugin to get our job done).

          Our goal is to use profiles to search/replace tokens in the src/deploy/webinf directory to end up in the final package (war file). We do this by setting up a plugin execution to run maven-resources-plugin during the process-resources phase. The snippet is as follows:

          <execution>
          <id>webinf-resources</id>
          <phase>process-resources</phase>
          <goals><goal>resources</goal></goals>
          <configuration>
          <outputDirectory>$

          {project.build.directory}

          /$

          {project.build.finalName}

          </outputDirectory>
          <resources>
          <resource>
          <targetPath>WEB-INF</targetPath>
          <directory>$

          {basedir}

          /src/deploy/webinf</directory>
          <filtering>true</filtering>
          </resource>
          </resources>
          </configuration>
          </execution>

          In the current version of the plugin, these resources are simply ignored. The plugin must be used because both the output directory and the target path need to be specified (no other combination is possible, trust me, I tried everything). Is there really any reason why the resources configuration node cannot simply be handled in the plugin without major refactorings?

          Show
          Dan Allen added a comment - I must chime in here because the root cause of this issue report has caused me extreme headaches. In my mind, and everyone sitting around me on the CM team, this is a MAJOR oversight in the resources plugin. Regardless of how it is fixed, it really just needs to be fixed (to get it out there) and then refactored. I will explain my use case and prove how badly we need this patch to go in (otherwise we will forever maintain our own version of this plugin to get our job done). Our goal is to use profiles to search/replace tokens in the src/deploy/webinf directory to end up in the final package (war file). We do this by setting up a plugin execution to run maven-resources-plugin during the process-resources phase. The snippet is as follows: <execution> <id>webinf-resources</id> <phase>process-resources</phase> <goals><goal>resources</goal></goals> <configuration> <outputDirectory>$ {project.build.directory} /$ {project.build.finalName} </outputDirectory> <resources> <resource> <targetPath>WEB-INF</targetPath> <directory>$ {basedir} /src/deploy/webinf</directory> <filtering>true</filtering> </resource> </resources> </configuration> </execution> In the current version of the plugin, these resources are simply ignored. The plugin must be used because both the output directory and the target path need to be specified (no other combination is possible, trust me, I tried everything). Is there really any reason why the resources configuration node cannot simply be handled in the plugin without major refactorings?
          Hide
          Andreas Ebbert-Karroum added a comment -

          – two months later –

          is there now a fix to this problem available? Or another plugin with which you can copy around in your project at wish?

          Show
          Andreas Ebbert-Karroum added a comment - – two months later – is there now a fix to this problem available? Or another plugin with which you can copy around in your project at wish?
          Hide
          Stian added a comment -
          • over a year later -

          Any answers to Andreas' questions yet?

          Show
          Stian added a comment - over a year later - Any answers to Andreas' questions yet?
          Hide
          sleberrig added a comment -

          Any activity on this issue:

          I just ran into this today. Needed to copy/process some resources before the integration phase but impossible to set the resource directory. As suggested there should either:

          • be the possibility to specify resources to include
          • or a separate mojo that would copy any resource to any directory.

          Our work around for the moment, using ANT, not really nice...

          Show
          sleberrig added a comment - Any activity on this issue: I just ran into this today. Needed to copy/process some resources before the integration phase but impossible to set the resource directory. As suggested there should either: be the possibility to specify resources to include or a separate mojo that would copy any resource to any directory. Our work around for the moment, using ANT, not really nice...
          Hide
          Olivier Lamy added a comment -

          IMHO adding a mojo called copy-resources is the best option here.

          Show
          Olivier Lamy added a comment - IMHO adding a mojo called copy-resources is the best option here.
          Hide
          Salvador Diaz added a comment -

          I just ran into this issue, I was willing to submit a patch but I saw that it was already submitted, any chance to release the patched version of the plugin to the central repository ?

          Show
          Salvador Diaz added a comment - I just ran into this issue, I was willing to submit a patch but I saw that it was already submitted, any chance to release the patched version of the plugin to the central repository ?
          Hide
          Arnljot Arntsen added a comment -

          We are experiencing the same problem here. Though through the MWAR-12 improvement which is supposed to let you process resources (such as web.xml).

          If we put the resources and filter directly under build element in the pom, and change to jar. It's filtered and all is good. But no matter where and how we have the filter and resources (under build, under webResources or under configuration.resources) it's being completely ignored when having the packaging as war.

          From reading it seem's that it's a bug with MRESOURCES and not with MWAR?

          Show
          Arnljot Arntsen added a comment - We are experiencing the same problem here. Though through the MWAR-12 improvement which is supposed to let you process resources (such as web.xml). If we put the resources and filter directly under build element in the pom, and change to jar. It's filtered and all is good. But no matter where and how we have the filter and resources (under build, under webResources or under configuration.resources) it's being completely ignored when having the packaging as war. From reading it seem's that it's a bug with MRESOURCES and not with MWAR?
          Hide
          Olivier Lamy added a comment -

          The question is : we call this new mojo copyResources or copy-resources ?
          My +1 for copy-resources.
          Comments are welcome !
          Thanks,

          Olivier

          Show
          Olivier Lamy added a comment - The question is : we call this new mojo copyResources or copy-resources ? My +1 for copy-resources. Comments are welcome ! Thanks, – Olivier
          Hide
          Benjamin Bentmann added a comment -

          +1 for copy-resources, that matches the majority of goal names.

          Show
          Benjamin Bentmann added a comment - +1 for copy-resources, that matches the majority of goal names.
          Hide
          Olivier Lamy added a comment -

          Implemented in rev 694813
          I leave the issue open until there is more tests and documentation.

          Show
          Olivier Lamy added a comment - Implemented in rev 694813 I leave the issue open until there is more tests and documentation.
          Hide
          Olivier Lamy added a comment -

          Do we have to attach this mojo to phase ?
          IHMO no.
          But comments are welcome
          Thanks!

          Show
          Olivier Lamy added a comment - Do we have to attach this mojo to phase ? IHMO no. But comments are welcome Thanks!
          Hide
          Olivier Lamy added a comment -

          junits, its and example in site are ok.

          Show
          Olivier Lamy added a comment - junits, its and example in site are ok.
          Hide
          Benjamin Bentmann added a comment - - edited

          Olivier, given that users apparently cannot override the parameter resources from the ResourcesMojo, should we mark it @readonly to hide it from the plugin docs and prevent future confusion?

          Show
          Benjamin Bentmann added a comment - - edited Olivier, given that users apparently cannot override the parameter resources from the ResourcesMojo , should we mark it @readonly to hide it from the plugin docs and prevent future confusion?
          Hide
          Olivier Lamy added a comment -

          Good idea !

          Show
          Olivier Lamy added a comment - Good idea !

            People

            • Assignee:
              Olivier Lamy
              Reporter:
              Leszek Gawron
            • Votes:
              17 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: