There are several plugin issues which are affecting plugin developers while building plugins, here are a list of the most prevalent. If you are solving (or have solved) an issue, please add your name to aid collaboration.

The Hit List

These are the most important issues to plugin developers on a whole (ordered by priority):

1. HTTP Headers of Resources Served from Plugins
2. Plugin Reloading
   1. Components Break when Reloading
   2. Servlet Plugins don't unload
   3. Aggressive Velocity Caching
3. Plugin Library Dependencies
4. Variable Case Sensitivity in Plugin Key Handling
5. Configurable Plugins
6. Space/Admin Menu Panels/Items
7. Plugin Repository (aka Plugin Downloading)
8. Bandana / XStream storage

Note: the order of the hit list may well change over time as discussions within the developer community are held.

Plugin Development Issues

Here is more detailed information about the issues involved.

Configurable Plugins

Solved!	Mike Cannon-Brookes
Issue	CONF-3725

Themes are configurable by specifying an xwork action to use for the [configure] link next to them. It would be really useful if plugins could also have this configuration link. I don't think there is much of a current need for individual plugin modules to be configurable, but if one arises, that could be an extension to the configurability of plugins as a whole.

See Writing Confluence Plugins for details on how to do it (changes are backwards compatible so plugin authors can put these links in now).

Space/Admin Menu Panels/Items

Solved!	Charles Miller
Issue	CONF-3724, CONF-4273

This was solved with the introduction of Web UI Plugins.

With the exception of macros, plugins are generally inaccessible - adding in menu links through extending the current navigation is getting more and more of a problem. Being able to extend the space / admin menu panels would resolve this visibility problem.

Plugin Reloading

This is really a number of issues, all of which affect the uninstalling and reinstalling of uploaded plugins.

Aggressive Velocity Caching

Solved!	Mike Cannon-Brookes
Issue	CONF-3326

When a plugin is reinstalled, it's velocity files are not flushed. Currently the only options are either to restart, to disable velocity caching - which obviously would be unwise on a production installation, or to disable and then re-enable any plugin which triggers a call to ConfluenceVelocityResourceCache.clearAllCaches()

Components Break when Reloading

You can work around this (at least for my experience) by disabling the plugin before uninstalling it and enabling it again after re-installation. I did once come around a problem with this work around, but I have since been unable to replicate it. The following was found after my research:

While playing around inside atlassian-plugins, I have found that uninstalling a plugin does not cause it's modules to be disabled. The code is there to do it, but its not working - I think it has something to do with the order in which you are removing the plugin from the map.

com.atlassian.plugin.DefaultPluginManager in confluence-2.1.3-source/plugins/src/java

plugins.remove(plugin.getKey());

       for (Iterator it = plugin.getModuleDescriptors().iterator(); it.hasNext();)
       {
           ModuleDescriptor descriptor = (ModuleDescriptor) it.next();

           // if the module is StateAware, then disable it (matches enable())
           if (descriptor instanceof StateAware && isPluginModuleEnabled(descriptor.getCompleteKey()))
               ((StateAware)descriptor).disabled();

           // now destroy it (matches init())
           descriptor.destroy(plugin);
       }

       loader.removePlugin(plugin);

In this code "isPluginModuleEnabled(descriptor.getCompleteKey())" always returns false, even when the same logic in the "disablePlugin" works. I have made too many modifications to test without reverting, but I am hazarding a guess that the "plugins.remove(plugin.getKey())" might be causing the problems.

The problem can be replicated by taking any plugin that has a component module, installing it, uninstalling it and the installing it again. During the uninstallation the ComponentModuleDescription.disabled() method will not be called.

However this can be worked around by installing it, disabling it, uninstalling it, installing it again and enabling it - and it'll work fine. The ComponentModuleDescription.disabled() will be called as it should during disabling.

I hope this narrows down the search for the bug. Sorry I didn't take it the extra mile, I'm strapped for time tonight.

Dan Hardiker

Servlet Plugins don't unload

Solved	Charles Miller
Issue	CONF-5598

A servlet plugin will load fine the first time, but will not unload/reload when the plugin is uninstalled/reinstalled. In fact, it doesn't seem to unload, uninstall, or even disable at all. If you disable the servlet, it still keeps running. If you uninstall the plugin, the servlet keeps running. If you disable it, then uninstall the plugin, the servlet keeps running. It just will not die...

Half of this problem is fixed in 2.1.5, the other half in 2.2. See CONF-5598

Plugin Repository (aka Plugin Downloading)

Solved!	Dan Hardiker
Issue	none

Any help with this resource will be useful: [Confluence Build Information]

See the [Confluence Repository Client] and the [Confluence Plugin Repository] for more details.

Plugin Library Dependencies

Solved!	Dan Hardiker
Issue	CONF-4401 CONF-4638

See [Plugins - Recursive JarClassLoader] for a fix.

David Peterson requested that plugins be able to access other plugins classes. There has however been a strong case for plugins to bundle the libraries they depend upon. After many discussions the general consensus has turn out to be that plugin's should include their dependencies as JARs bundled inside their own plugin JAR.

This will mean that David's utilities plugin will still need to be uploaded - otherwise each dependant plugin must release multiple versions for each version that the utilities plugin offers transparent compatibility for. Alternatively, the compatibility layer which utilities offers could be accepted into the standard distribution - however that will involve vetting (and time).

David Peterson - I will be quite happy to switch to having embeded libraries as opposed to the separate Utilities plugin - you have no idea how many times I have had to explain how to install the darn thing. A single .jar plugin would be much nicer.

HTTP Headers of Resources Served from Plugins

Solved!	Dan Hardiker
Issue	CONF-5418 CONF-4281

There are a number of heading missing from resources which are downloaded through the resource plugin module type. The most notable are the Last Modified and ETag headers which is crucially required for the caching of resources. As many of the standard HTTP headers which can be offered should be included where possible - although the Last Modified (and possibly ETag) are the most critical.

See Supporting Conditional GET When Serving Plugins Downloadable Resources for the patch.

Bandana / XStream storage

When a plugin stores objects in Bandana, the restoration process causes exceptions with the XStream classloader being unable to "see" the plugin's classloader. With that issue fixed there is still the problem of XStream throwing exceptions when a plugin that leaves information in custom class data stored in bandana is uninstalled.

Dan Hardiker I have worked around these issues by implementing his own "plugin bandana" which uses it's own files. It would be nice if Bandana could be given a file to use - I have done it by the way of a BandanaConfiguration object.

(Andrew Lynch) See my comments at http://jira.atlassian.com/browse/CONF-6655?focusedCommentId=103377#action_103377 if you are not providing a no argument constructor in your custom type.

Variable Case Sensitivity in Plugin Key Handling

Solved	Mike Cannon-Brookes
Issue	CONF-4478 CONF-4903

See the problem discussed here, and the warning posted here. A simple "toLowerCase" on the key (as well as on the key look up in the macro call) might fix those problems making all keys case-insensitive.

Others Issues

Please add your plugin development woes, and tag it to the end of the hit list..