Hi All,
I've been looking at this issue for some time now as well and have come up with a some what less complex solution, but it seems to work for me and may just as well for some of you.
Let me start by saying why this I need to have "add resource filtering to war plugin". Quite simply, I'm using JBoss and I need to change values in the WEB-INF\jboss-web.xml deployment file at build time. An example would be the <context-root> tag among others. So yes, there is reason to have resource filtering in this plugin... well kind of.
In order to understand my solution to this issue I think I need to explain the interaction that I belive actually happens between the war and resource plugins so that we are all on the same page.
The first behavior I noticed is where the two plugins write their output to. When the resource plugin writes out to the target folder, it does not respect the <finalName> tag in the POM like the war plugin does. I belive its default output folder is target/<project.artifactId> or something like that. On the other hand, the war plugin, when writing its output will first look for the <finalName> tag from the POM and if its there will use it and create a folder like this ~/>target/<finalName>. If it does not find a <finalName> tag in the POM it will then use something like ~/>target/<project.artifactId><project.version>. What this leads to is, most of the time there will be two sub-folders under the ~/>target/ directory (which leads into next issue, but more on that later). The exception to this is if the <finalName> tag and the <project.artifactId>-<project.version> tags where some how set to equal the same thing, then when each of the plugins write their output one will overwrite the other resulting in one sub-folder under the ~/>target directory.
The second issue/behavior I have already inherently stated. That is that war and resource plugins both do to a copy of the ~/>src/main/webapp directory to the ~/>target folder one after the other when you run the war plugin. Its the combination of these two behaviors that cause some nasty things to happen.
(DON'T TAKE THEASE EXAMPLES AS LITERAL)
Lets say that in the first example your POM is setup like this:
<project>
<artifactId>filtered-webapp</artifactId>
<build>
<finalName>webapp</finalName>
</build>
</project>
so that you will end up with a ~/>target folder like this:
/>target
filtered-webapp
webapp
and the problem is that the files from ~/>src/main/webapp will get filtered but the output from the resource plugin is in the />target/filtered-webapp folder, but when the war plugin builds the *.war file it is going use the files in the />target/webapp folder which have not been filtered!
For the second example lets say that the POM looks this:
<project>
<artifactId>filtered-webapp</artifactId>
<build>
<finalName>filtered-webapp</finalName>
</build>
</project>
so that you will end up with a ~/>target folder like this:
/>target
filtered-webapp
the main issue here is this. The resource plugin is going to read the ~/>src/main/webapp files and then filter them and write its output to the ~/>target/filtered-webapp folder. Then the war plugin is going to come along and grab a copy of the same ~/>src/main/webapp folder and write its output to the same ~/>target/filtered-webapp folder undoing the filtering the resource plugin just did. Then the war plugin will again use that same ~/>target/filtered-webapp folder to build the war file.
So as you can see in the current situation you can't win, either way you can not get filtered files into your webapp.
The solution I came up with does not add resource filtering to the war plugin just as someone else had suggested. It does not even add any new tags to the POM. It just tweaks the way these two plugins interact with each other. The funny thing about this whole thing is the solution I came up with is very simple. I patched the ResourcesMojo class so that it always writes its output the <finalName> tag from the POM just like the war plugin does. Then I patched the AbstractWarMojo class so that it first checks to see if there is an existing target/webapp folder before it create its own (so that it does not overwite one that the resource plugin may have put there) and copies the ~/>src/main/webapp to it.
I have been using this fix for a few weeks now and it seems to work just fine in all situations for me, but I'm sure some of you will most definitely find a fault in it somewhere. But I figured I share my experience and post the patches anyway, because the group may find some use of it. So here are the patch files...
Scott
Improvement
Closed
Major
What I really like to see is the removal of warSourceDirectory. It should be just a resource directory,
specified in a <resource> section, with a different <targetPath> (the exploded war dir, not the WEB-INF/classes
dir or even the classes/ dir), or something like that. THe resources plugin should take care of copying it.
Here's a nice solution (I think):
Add a new mojo to the war plugin and bind it to a pre process-resources phase.
That mojo will take care of registering the (still existing) warSource directory as a resource root.
When process-resources is up, the resources plugin will pick that directory up and copy it, applying filtering.
The problem here is how to specify filtering - we don't want to do that in more than one place, if possible:
everything in MNG-788 would be duplicated for the configuration of this mojo then..
So we could specify the warSource directory as in a <resource> section too, where filtering can be specified.
It should somehow be marked as being the warSourceDirectory, for instance if the <directory> matches
the warSourceDirectory configuration (src/main/webapp). If there are no matches, the new mojo will
have created a resource section with default values.
If there exists one or more matching resource sections, a problem can be that targetPath is specified - what if it
doesn't match the temporary exploded webapp directory in target/ ?
If targetPath is not specified, the mojo will set the targetPath to the warSourceDirectory (for matching resource
sections!). normal resources go in target/classes, these should go in the exploded webapp root (not in WEB-INF/classes either).
Or there might be another, more general way to mark the resource for use of a specific plugin..