Q:

Yui invalidate javascript browser cache with new release

I have YUI project that is mavenized. When we release new YUI code, it is not reflected right away in the browser, until you do SHIFT + REFRESH on browser. 
I have been using YUI modules approach to load scripts like this:
YUI.GlobalConfig = {
   modules: { 

 'manual-entry-util': {
        fullpath: 'resources/js/common.js',
        requires: [ 'node']             
    },
    'user-perm-util' : {
        fullpath: 'resources/js/userPermUtil.js',
        requires: [ 'node',  'io-base', 'json', 'json-stringify']       
    }, 
    'file-upload-custom' : {
        fullpath: 'resources/js/fileUploadCustom.js',
        requires: [ 'gallery-datatable-selection','event-custom', 'node']       
    },
    'icsd-uploader' : {
        fullpath: 'resources/js/icsdUploader.js',
        requires: [ 'uploader', 'node']     
    },
    'ui-util' : {
        fullpath: 'resources/js/uiUtil.js',
        requires: [ 'node']     
    } 
    } 
}; 

I believe we need to modify the urls to have some sort of variable so that new code can be picked up by the browser. 
Is there a way to automate this process via maven or some other tool. E.g. which can generate the hash value from the contents of the .js file and then add that to the url of .js file?

A:

We use a variant of the answer from @blicksky. We built our own combo-loader as a servlet. 
Firstly, we set up YUI as it's own Maven project. The version tag reflects the release of YUI, so your version would look like <version>3.17.2</version. We have an in-house repo, so any update to the YUI project gets published there. The YUI project just houses a copy of YUI in /src/main/resources/META-INF/resources. In this respect it's pretty similar to the approach taken by the WebJars project.
The Combo-loader takes care of concatenating the YUI files together for better loading performance and is also responsible for adding a cache-busting URL parameter. In production that parameter is the Build ID, but in development, that parameter can be a random number, so that the resources are loaded each time. We're using Spring on the server, so we use the Classpath to resolve YUI files that come from the YUI Maven project mentioned above. The basic gist is that our Servlet implements ResourceLoaderAware and can then use the ResourceLoader to pick up YUI files to serve up. 
The approach has served us well and also allows us pretty fine-grained control of how the files are served, as well as improving load-times.

