Javascript and CSS versioning in portlets

[11年前 に Dana Oredson によって更新されました。]

I have been investigating versioning/cache-busting strategies, so that any time certain files change (via deployment), users will get the new file.

For example:
1) User visits my page that has a portlet on it. The portlet has some javascript files.
2) User's browser caches the JS file
3) Several weeks later, I deploy a new feature or bug fix that changes the javascript file served by my portlet
4) User's browser does not download the new file (oops!) because it's cached. (This is the step I'm trying to fix).

Currently, my portlets have entries in liferay-portlet.xml for CSS and JS specific to them. For example:
<footer-portlet-javascript>/js/main.js</footer-portlet-javascript>

I would like to be able to do something at build time that sets the path in liferay-portlet.xml to something new, so that the user's browser will recognize it as a file that needs to be downloaded.

I've looked at JAWR, and have read articles like this: http://raibledesigns.com/rd/entry/versioning_static_assets_with_urlrewritefilter
However, this don't address the situation that we have with Liferay, where we have this liferay-portlet.xml file that has the paths to the JS and CSS files, versus being in a .jsp, where JAWR would know how to find/update it at build time.

I would still like to use my entries in liferay-portlet.xml, versus rolling my own in each JSP file, so what ideas do you all have for doing this? Ideally, I would be able to put a variable in the XML tag, such as this and have either liferay or maven update it to the appropriate value at build time:
<footer-portlet-javascript>/js/${version}/main.js</footer-portlet-javascript>
evaluates to:
<footer-portlet-javascript>/js/1/5/main.js</footer-portlet-javascript>

Thoughts?

[11年前 に David H Nebinger によって更新されました。]

The complexities here revolve around how ${version} is resolved...

Is it a build version? Probably not, it's probably tied to a file version. Since the deployed portlet only has one version (normally), then there is no real version there either. You can't really depend on file timestamps as they will be updated during deployment...

To keep things simple, I'd just change the name and/or path of the actual main.js file and also change it in liferay-portlet.xml manually. That way you know that the deployed portlet will refer to an updated main.js variant that you want the caching user to refresh...

Otherwise, I think the changes you're talking about are pretty extensive (hot deploy code changes, build process code changes, etc.)...

[11年前 に Dana Oredson によって更新されました。]

I can use maven plugins to resolve variables at runtime in resources, but for the hot-deploy case, the maven build does not run, so I would need liferay to not puke when it sees ${version} in liferay-portlet.xml

What implements the actual placing of the JS and CSS files that are noted in liferay-portlet.xml onto the resulting HTML file? If I could specify a handler JSP either in liferay-portlet.xml or in my portlet's bundled portal.properties or perhaps a hook, then I could have maven replace the value in the JSP at build-time or have the JSP itself determine if ${version} is set and if so render that in the final URL for each linked resource (JS and CSS). Then just use a urlrewrite filter, as suggested in some blogs, to resolve the version to the real file at runtime (thus breaking the cache).

[11年前 に David H Nebinger によって更新されました。]

Well unfortunately this throws you into the bowels of Liferay (the reading of the liferay-portlet.xml, the handling of the generation of the <script /> tag on the full page, etc.). Even if you managed to patch and/or hook this logic into the version you're currently running, I doubt that would be portable to previous or future versions of Liferay.

Why don't you just generate liferay-portlet.xml on the fly during the build? You can handle all of the variable replacement, file moving, etc. through some fancy maven legwork, and that keeps you out of having to try to hack Liferay trying to make this happen...

[8年前 に Tushar Patel によって更新されました。]

Thanks We have used same logic in our ant build script and changed liferay-portlet.xml while creating war.

[8年前 に Marek Tracz によって更新されました。]

Thank you! Now, we are changing liferay-portlet.xml while creating war with maven replacer plugin.

Check this out here:
https://code.google.com/archive/p/maven-replacer-plugin/wikis/UsageWithOtherPlugins.wiki