Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

Confluence third-party developers are likely to start running into mentions of “Plugins 2.0” in existing code and in future milestone releases. As such, I thought it might be a good idea to give you a quick heads-up on what is happening in Atlassian HQ, and how this is going to affect plugin authors.
The short version:
# We are moving to an OSGi-based plugin system.
# You don’t have to know OSGi to write a plugin, and
# existing plugins will continue to work fine, but
# if you want to leverage OSGi, you can.


h3. Why OSGi?
Since the days of Confluence 1.0, we’ve been building our own plugin system alongside Confluence, imaginatively named “atlassian-plugins”. This library started off as a way to add new macros to Confluence’s wiki markup, but developers quickly demanded more, so the plugins system grew to cover more of Confluence’s APIs, load their own dependencies, and support dynamic loading and unloading of modules.
There are a number of plugin feature requests outstanding, though:
* more robust Spring component plugins
* the ability for plugins to depend on each other
* control over plugin load order
* the ability for plugins to define their own extension points
* more consistent plugin APIs between products
Any one of these would require a significant rewrite of the existing plugin system. Luckily, the Java community has already done a lot of the work for us in the form of OSGi.
OSGi is the de facto standard for Java component/plugin systems. It provides APIs for deploying plugins, managing their lifecycles and dependencies, and keeping plugins isolated from each other. It’s widely deployed and robustly tested: any Java developer who uses the Eclipse IDE is already using OSGi every day.
h3. Backwards Compatibility
OSGi is very different to the existing plugins system, so we wanted to ensure that developers could continue to write Confluence plugins without having to learn OSGi. Converting an existing plugin into a “2.0 plugin” will involve making one small change to the atlassian-plugins.xml file, and Confluence will do the hard work of generating the OSGi manifest for you.
Some plugin types may behave differently in the 2.0 container. For example, component plugins currently add their beans to Confluence’s main Spring context, in 2.0 they will be deployed in separate contexts using Spring Dynamic Modules. We will try, however, to keep things as consistent as possible.
Plugins that don’t have the 2.0 flag set will continue to be loaded by the old plugin loader, and work the same way they always have. I suspect some time in the reasonably distant future we will drop support for “1.0 plugins”, but that’s not even on any roadmap for now. It is likely, however, that future improvements to the plugin system will be 2.0-only.
h3. Roadmap
The current, tentative plan is that the next major release of Confluence (late 2008) will have *experimental support* for Plugins 2.0. It will be available, and we may be making use of it internally, but third party developers will have to remember that it is a brand new system, largely untested in the wild, that may change radically over the course of the release.
That said, if you enjoy living on the bleeding edge we will looking for feedback from implementors, especially regarding which Confluence packages and components we make available to plugins. Look for the feature in Confluence 2.10 milestone releases.
By early 2009, we should have everything bedded down properly and Plugins 2.0 will be the New Way of Doing Things.
h3. Documentation
Right now, there isn’t any. Which is fine because you wouldn’t be able to do anything with it now anyway. Don and Sarah are slaving over a hot wiki so that by the time you _can_ take advantage of the new plugin system, it will be nicely documented for you.
h3. JSR-277
JSR-277 is the Java Community Specification Request for dynamic modules. There is a significant overlap between JSR-277 and OSGi, but it’s not clear yet whether this will be one of those situations where the _de facto_ and _de jure_ standards converge (like Hibernate and JPA), or stay messily separate (like log4j and the Java Logging API). Regardless, since JSR-277 is going to be included in Java 7 at the earliest and Confluence has only just been able to embrace Java 5, we have some time before this becomes an issue for us.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now