jira-importer commented on issue #160: URL: https://github.com/apache/maven-war-plugin/issues/160#issuecomment-2967846798
**[Scott Tavares](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stavares)** commented 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 over write 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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
