Hmm, I see there's a longstanding issue with this... http://
jira.codehaus.org/browse/MWAR-12
I'd kind of like to solve this...
-b
On Feb 20, 2006, at 12:51 AM, Brian Topping wrote:
Hi folks,
I've been working on web resource filtering with the war plugin and
came across a consideration I'd like to ask of the group.
What do you think of the term "resources" in the context of a war?
To me, <resources> in the POM should be considered anything
including the webapp resources, not just classpath resources. I
see this because classpath resources could easily be added to $
{warSourceDirectory}/WEB-INF/classes and used from there.
In this manner, ${warSourceDirectory} could be filtered with the
same constructions people are used to with the resources plugin.
This is the way I initially expected things to work. Brett felt
otherwise when I talked to him on IRC, but he also said he doesn't
do filtering with webapp content and I ought to ask people who care
a little bit more about this subject.
OPTION 1:
<resources> are added to plugin configuration. Someone who wanted
to filter their webapp resources would need to add a complete
<resources> configuration to their POM, such as:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0-beta-3-SNAPSHOT</version>
<configuration>
<resources>
<resource>
<directory>src/main/webapp/WEB-INF</directory>
<filtering>true</filtering>
</resource>
</resources>
<filters>
<filter>
<filterproperties>${basedir}/src/main/
webapp/WEB-INF/classes/build.properties</filterproperties>
</filter>
</filters>
</configuration>
</plugin>
In this configuration, we still have overlap with the
warSourceDirectory parameter to the war plugin and extra code needs
to be added to deal with the circumstance that either/both are
specified.
OPTION 2:
Existing semantics for the resource plugin are preserved, but
interpreted slightly differently based on the <packaging>. When
<packaging>war</packaging>, we treat the <resources> as components
of the webapp. I think this significantly simplifies the user
experience.
Opinions?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
