Maven webResources filtering on-the-fly

I'm using the maven-war-plugin to filter some resources in WEB-INF. Mostly stuff static stuff like:

var url = ${contextRoot}/save.json;

or

<link href="static/css/layout-${buildNumber}.css"/>

Everything works fantastically. My issue is that it has created a development nightmare. I typically hot deploy to a local tomcat and my IDE handles copying change开发者_Go百科s (on save) to the target directory. But when that happens I end up with a literal ${property} in my file instead of what it was originally replaced with by the war plugin. I would prefer to test view/static resource changes on-the-fly instead of having to redeploy for each change.

I've messed around with the tomcat plugin to run it but when I used that the resource filtering doesn't happen unless I use it to deploy, in which case I lose the hot-swap capabilities.

I'm using spring and I would be fine with using themes, filtering the theme properties, and then using that to replace values in my view. But what about the js/css/other static stuff?

Is there a way to have the war plugin "filter on-the-fly"? Can anyone recommend a better way accomplish what I'm trying to do? I feel like I've been looking at it for too long and have some tunnel vision on the matter.

---

If you use eclipse with m2e and m2e-wtp, you can get on-the-fly web resource filtering. This is explained here : https://community.jboss.org/en/tools/blog/2011/05/03/m2eclipse-wtp-0120-new-noteworthy

And demoed there : http://bit.ly/wGcD4j

Note that, in this video, the Maven Profile Management UI is coming from JBoss Tools 3.3.0.Beta1 (http://docs.jboss.org/tools/whatsnew/maven/maven-news-3.3.0.Beta1.html)

---

In the end I kept the same methods but changed my approach to accomplish this.

For Javascript, I put anything that needs to be filtered into a single Constants file:

// Constants.js

var BASE_URL = '${contextRoot}';

The reason behind this is that the Constants.js file will very rarely be modified and avoid the problem of having that file redeployed on the fly.

My other example was using ${buildNumber} to avoid browser resources caching across deploys. I found that appending the build number to a query string worked just as well:

<link href="static/css/layout.css?${buildNumber}"/>