Editor loader resources not batched when plugin installed

[Ulrich Kuhnhardt [Comalatech]]

When testing Ad hoc Canvas (addon-com.comalatech.adhoccanvas) with Confluence 5.2.2 we observe that comment editor loader resources are not batched. All comment editor resources are loaded separately like http://cl.ly/image/2f2J3c2h3G2p . If the plugin is disabled comment editor resources are batched like http://cl.ly/image/1A3r461W2r1w.

This causes problems when using IE9 + Confluence 5.2.2 + Ad hoc Canvas due to some CSS file limit per page load in IE mentioned before.

The Confluence 5.1.4 always loads batched editor resources when Ad hoc Canvas is installed like http://cl.ly/image/3o0e2S3O3k0T.

Any idea what may cause the Confluence web resources manager to fail batching comment editor resources?

[Joe Clark · Accepted solution]

Hey Uli,

I replied to the email you sent me about this, but I wanted to add a public answer as well in case others come across this.

This is caused by new behaviour in the plugins system in Confluence 5.2 (specifically, there's new behaviour inv3.0.0 of the atlassian-plugins-webresource plugin). In particular have a look at the addContextBatchDependencies method. In an attempt to prevent resources from being included on the page more than once, if a resource within a batch has been detected as already having been served to the client, then the batch containing that resource will be de-constructed and served as individual files, instead of being served as a batch.

What this means, for Confluence plugins, is that you will consistently run in to this problem if you have web-resources that exist in both the atl.general and editor context, you will cause the editor context to become un-batched.

The solution is to enforce a clear separation of concerns between your view resources and your edit resources within your plugin, so that your resources do not overlap between these contexts.

[Ulrich Kuhnhardt [Comalatech]]

Thanks Joe for your comprehensive answer. As always - spot on.

[Joe Clark]

I just had a chat with some of the Confluence devs and this same bug was recently just encountered by a bundled plugin. This has definitely created a new "gotcha" for plugin development that is not a good experience for developers. There is a long-term solution in the works to solve this problem, but it may be some time before it is shipped.

[Joe Clark]

"Non-batched mode" still exists - it is possible to request an individual resource to be served from Confluence (and other Atlassian apps). My point on that other question is that it is no longer advisable for a plugin to statically opt-out of batched mode. Whether or not a web resource is batched should not be controlled at compile time - it should be a runtime decision.

[Ulrich Kuhnhardt [Comalatech]]

@Atlassian : so if you're saying non-batch mode is not an option any more why is it not working in this case?