[ http://jira.codehaus.org/browse/MRESOURCES-8?page=comments#action_58869 ] 

Dan Allen commented on MRESOURCES-8:
------------------------------------

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?

> maven-resources-plugin ignores configuration/resources property
> ---------------------------------------------------------------
>
>          Key: MRESOURCES-8
>          URL: http://jira.codehaus.org/browse/MRESOURCES-8
>      Project: Maven 2.x Resources Plugin
>         Type: Bug

>     Reporter: Leszek Gawron
>     Assignee: Brett Porter
>  Attachments: MRESOURCES-8-workaround.patch, example.zip, pom.xml
>
>
> 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?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to