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 changes (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.
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:
The reason behind this is that the
Constants.jsfile 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: