Universal Plugins

Something dawned on me earlier this week and during a chat with Don Brown from Atlassian, banded around the following questions: Can we have a universal plugin, in the same ways that there are universal binaries? What's stopping us? How can we improve things?

The following proposal came out of the answers:

Plugin Pain

The following scenarios are painful, especially when dealing with plugin development for Atlassian products:

• A plugin that works on multiple Atlassian products, where you want different logic to run in each (e.g. to access data)
• A plugin that needs to be compatible with multiple versions of a product, where there have been API changes
• A plugin that wants to use new Java 5 / 6 features and APIs if they are available, but degrade functionality on older JVMs

They all share one common point of pain, they require you to release multiple versions of the plugin to deal with the various environments they deal with.

A Better Way?

I would like to propose multiple atlassian-plugin*.xml files, similar to how there are multiple applicationContext*.xml files in Spring, with the added advantage that you can place restrictions into the <plugin-info/> element to determine what conditions this metadata file depends on.

This allows a number of options:

1. You can have a base manager interface, with 3 different implementations in 3 different files. This might be so that a different search API could be used, or that different logic could be done in a different product / application server.
   
   
2. You can run two compiles, covering two different packages, which compile using different JDKs - packaging both into the same jar, but only utilising one set of the bytecode through references in the appropriate atlassian-plugin xml file.
   
   
3. You can split up your code more logically, so if you have 30 macros - they can all go in one atlassian-plugin-macros.xml file, while the rest of the modules go in atlassian-plugin.xml. As all that match get loaded, it'll be as if the two were merged together into one file.

Notes

Loading Order

I would suggest that the xml files be processed in the order they come out of the jar file (which you can predict by viewing the contents of the jar in order, or use unzip -t file.jar). After discarding those that don't pass the restrictions,

Listen to Restrictions

Currently there are min and max version numbers, JDK version numbers etc - but for the most part they are ignored. The logic for testing needs to be put in, as well as adding in extra tests - such as for the JDK vendor. It would expect the possible restrictions to increase over time, and if an unknown restriction is specified then it assumes true.

Logging

As there's be a lot of things happening silently (as far as the normal operation is concerned); such as the filtering out of modules, unknown restrictions being found, survivable malformed metadata - there'll need to be well documented logging, and lots of it, so that plugin developers can get the information they need at development and debugging time.

Back-porting

If there was a way of back-porting this to even the last 2 or 3 "x.y" versions of Confluence, or an even wider scope (such as other products) this would make it instantly useful from the get go. We could utilise the fact that if an older version of Confluence doesn't have the back-port patch, then only the atlassian-plugin.xml file will be loaded to get around that fact.

Ultimately, if this isn't possible, it's only going to slow down the time at which this functionality really comes into it's own.