In Jira development, whenever a resource file like a .js or .css is changed, we are able to refresh the page in the browser and the changes will be loaded. Very convenient, and as expected.
But with Confluence, I’m noticing that any edits to .js or .css files made within the IDE are ignored, and that a full build & deploy cycle of the plugin must be performed for the changes to take effect within Confluence.
What am I missing? Or is this the state-of-the-art of Confluence Server/DC add-on development?
No, still unresolved. The closest technical approach we have is iframes.
Indeed, thought this might be the premier forum to jump into an ongoing discussion of the matter, but so far… just crickets? The current edit / build & reload plugin / reload page dev cycle is killer slow, a truly monumental waste of time and precious life span.
I can’t offer much in the way of support myself from my position, but I did try this out right now using “atlas-create-confluence-plugin” without OSGI config. I am using default js/css file hosted at atl.general. I am able to do a “hard-refresh” of the page and receive changes to the js/css resources without recompiling the plugin.
@aragot, did you resolve the issue? I’m dealing with the same issue…plugin.resource.directories property is pointing to the right directory but any change in js or CSS file is not being detected by the quick reloader plugin (tested in Confluence 7.13.11 with amps 8.6.0).
@GorkaGalloBustinza Apologies for a late response here, but I was having a similar problem.
Assuming you are using the Plugin SDK, it seemed that many 100s of files were being cached under target/confluence/home/webresource-temp.
Deleting all of these files in target/confluence/home/webresource-temp allowed changes made to JS/CSS files to actually be reflected on the running Confluence instance. However, that folder would quickly fill up again with cached files.
I am unsure of your exact setup but you may be able to devise a script to periodically empty that directory when changes are made, and that may fix your problem.
Thank you, @AndrewMorton . This is the first handle I get on solving this problem. I’m running a script every second now that empties this directory. A little ridiculous, but hey, it works.
EDIT: I just found out that I could complete remove the webresource-temp folder. Removing it stops Confluence from even trying to cache files. So, a little script kills the folder after every start of Confluence DC (because the folder is recreated on every start).
@SteffenMueller I’m glad it was useful! And I like your solution of using a script to delete the whole webresource-temp folder on startup, I think I’ll go with that from now on. Thank you!
Could you please tell me if you still experience this on newer versions of Confluence and QuickReload?
QR 4.0.0+ and Confluence 7.19+ is what I’m interested in. I’m also assuming y’all are pressing Ctrl/Cmd+Shift+R too.
FWIW if you update the AMPS version in your pom.xml to 8.11.0 or higher you’ll get the newer versions of QR and other developer tools (provided those versions aren’t overriden in the POM).
It’s easy for caching bugs to slip into the web-resource manager and into the products. There’s been a few cache busting fixes applied over the last couple of years and it may solve the problem. If the problem isn’t solved, I’m keen to hear it so we can build up a reproduction case and fix the bug.
Feel free to @me so I actually get emails from this thread
I will once again note that we can’t easily update the version of AMPS due to the fact that we’re still stuck on a 2.5 year old release of the SDK with an ancient Maven version because Atlassian apparently still can’t find the keys to publish a new version, and Atlassian specifically recommends to use the bundled Maven version that ships with the SDK.
The “we lost the keys” excuse is wearing very thin at this point.
