That's probably all we need to close discussion on it then.
Brett had the idea of doing <otherResources> as plugin
configuration. I'd rather err on the side of too verbose than
confuse people.
-b
On Feb 20, 2006, at 3:22 AM, Stephen Duncan wrote:
I'm like Brett, I haven't needed filtering in the webapp source yet.
But I think we'd need more details on how the second option would
work. My initial thought is that treating classpath resources and
webapp sources as "resources" is going to be really confusing...
-Stephen
On 2/20/06, Brian Topping <[EMAIL PROTECTED]> 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]
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
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]
