Maven war插件未按预期进行筛选

Question

我目前正在用maven 3.1.1和maven war插件2.4建立一个web项目(http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html). 特别是，我正在尝试用maven war插件复制和过滤资源，这种方式我在过去已经做过了，而且很有效。以下是相关pom配置：

WAR插件配置

...
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.1.1</version>
    <configuration>
        ...
        <webResources>
            <resource>
                <directory>src/main/webapp/META-INF</directory>
                <includes>
                    <include>**/*.xml</include>
                </includes>
                <filtering>true</filtering>
                <targetPath>META-INF</targetPath>
            </resource>
            ...
    </configuration>
</plugin>
...

激活的配置文件定义：

...
<profiles>
<profile>
    <id>dummyDev</id>
    <build>
        <filters>
            <filter>filters/development.properties</filter>
        </filters>
    </build>
</profile>
...

META-INF/上下文。xml：

<?xml version="1.0" encoding="UTF-8"?>
<Context reloadable="${tomcat.context.reloadable}">
</Context>

最后是“development.properties”：

tomcat.context.reloadable=true

context.xml被复制到WAR中，但没有被过滤。如果我尝试直接在配置文件中写入属性，它会起作用（即不引用属性文件）：只有当我引用thep属性文件时，它才会起作用。读取属性文件似乎有问题。此外，“打包”后，maven不会在控制台中告诉我找不到属性文件（所以maven找到了文件）。

最后，我试着用maven war插件2.1.1版（和2.3版）实现了这项工作，而且效果很好：我尝试了更多次，只是更改了maven war插件的版本，所以我很确定问题在于此。

我错过什么了吗？这是maven war插件的已知bug吗？我是否试图以正确的方式获得结果（过滤该文件）？谢谢

Answer 1

好吧，我搜索了maven war插件jira，发现这实际上是一个错误，在2.4版中引入（更多http://jira.codehaus.org/browse/MWAR-301）。

为了方便起见，我引用了jira问题中指出的解决方法：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        ...
        <filters>
            <filter>${project.basedir}/src/main/filters/my-filter.properties</filter>
        </filters>
    </configuration>
</plugin>

在我的皮肤上试过，效果很好。

无论如何，我注意到，如果您在这个位置指定一个属性源文件（这是pom级别的war插件声明，而不是概要文件级别），它将始终被读取，即对于您指定的每个构建概要文件。除非您为每个构建概要文件重新声明war插件，并在每个概要文件中指定一组不同的属性文件（这里指出的是一个非常糟糕的解决方案，只是为了说明这是错误的，而且为了完整性，显然是IMHO），否则此解决方案仅限于无论指定了什么构建概要文件，都必须始终读取给定属性文件的情况。