Confluence plugins provide a standard mechanism for extending Confluence. By adding plugins to Confluence you will be able to customise the site's look and feel, add new macros, event listeners, periodic tasks, and even introduce whole new features.
You can read Confluence Plugin Guide for an overview of what plugins are. This document introduces Confluence plugins to the developer who may want to write their own.
While Confluence plugins use the same plugin management code as JIRA 3.0 plugins, it's very unlikely that a JIRA plugin will work in Confluence or vice versa.
Anatomy of a Plugin
A plugin is a single jar file that can be dropped into Confluence's classpath. It consists of
- A plugin descriptor
- (Optional) Java classes
- (Optional) Resources
Plugins are composed of a series of modules, each of which defines a point at which the plugin interfaces with Confluence.
Creating a new plugin
See Creating a new plugin.
Confluence Plugin Module Types
The following types of plugin modules are supported by Confluence
Module Type |
Since version... |
Documentation |
Description |
codeformatter |
2.2 |
Code Formatting Plugins |
Adds new languages to the {code} macro |
colour-scheme |
1.3 |
Theme Plugins |
A colour-scheme for a theme |
component |
1.4 |
Component Plugins |
Allows developers to add components to Confluence's component system |
decorator |
2.5 |
Decorator Plugins |
Adds decorators without using a Theme Plugin |
extractor |
1.4 |
Extractor Plugins |
Adds information to the Confluence search index |
editor |
2.5 |
Editor Plugins |
Adds a Wysiwyg editor to the Confluence edit page |
job |
2.2 |
Job Plugins |
Adds repeatable jobs to Confluence |
language |
2.2 |
Language Pack Plugins |
Adds language translations to Confluence |
layout |
1.3 |
Theme Plugins |
A layout (decorator) definition for a theme |
lifecycle |
2.3 |
Lifecycle Plugins |
Schedule tasks to be run on application startup and shutdown |
listener |
1.4 |
Event Listener Plugins |
A component that can respond to events occurring in the Confluence server |
macro |
1.3 |
Macro Plugins |
A macro used in wiki to HTML conversions (e.g {color}). Outputs HTML that can be embedded in a page or layout. Can retreive user, page and space info, or external content (eg RSS) |
rpc-soap |
1.4 |
RPC Plugins |
Deploys a SOAP service within Confluence |
rpc-xmlrpc |
1.4 |
RPC Plugins |
Deploys an XML-RPC service within Confluence |
servlet |
1.4 |
Servlet Plugins |
A standard Java servlet deployed within a Confluence plugin |
spring |
2.2 |
Spring Component Plugins |
Add a Spring component. Unlike component plugins these allow the use of full Spring configuration XML |
theme |
1.3 |
Theme Plugins |
A custom look-and-feel for a Confluence site or space |
trigger |
2.2 |
Trigger Plugins |
Adds triggers which schedule jobs |
usermacro |
2.3 |
User Macro Plugins |
Allows a simple macro to be created in the plugin XML file, with no Java coding necessary |
velocity-context-item |
1.4 |
Velocity Context Plugins |
Adds helper objects to Confluence's Velocity context |
web-item |
2.2 |
Web UI Plugins |
Adds links or tabs to the Confluence UI |
web-section |
2.2 |
Web UI Plugins |
Adds sections of links to the Confluence UI |
xwork |
1.4 |
XWork-WebWork Plugins |
XWork/Webwork actions and views bunded with a plugin, enabling user interaction |
The Plugin Descriptor
The Plugin descriptor is an XML file that tells Confluence all about the plugin, and the modules contained within it. The descriptor must be a single file named atlassian-plugin.xml
and must be located at the root of the jar file. Here's a sample plugin descriptor:
<!-- Every plugin must have a key, which identifies the plugin uniquely to the system -->
<!-- and a name, which is used to display the plugin in menus. -->
<atlassian-plugin key="com.atlassian.confluence.plugins.example"
name="Example Plugin">
<!-- The plugin info block allows you to provide more information about your plugin -->
<plugin-info>
<description>
A sample plugin for demonstrating the file format.
</description>
<version>1.0</version>
<!-- the versions of the application this plugin is for (both min and max are mandatory) -->
<application-version min="1.3" max="1.3"/>
<vendor name="Atlassian Software Systems Pty Ltd" url="http://www.atlassian.com/"/>
</plugin-info>
<!-- Here is where you define your modules. The code you use -->
<!-- to define a module depends on the module itself. This is just -->
<!-- a sample, which will not load if installed into Confluence -->
<!-- Modules must have a key that is unique within the plugin, a name -->
<!-- and an implementing class. -->
<example key="module1" name="Example Module"
class="com.atlassian.confluence.plugins.example.ExampleModule">
<!-- All modules can optionally have a description -->
<description>An example module</description>
</example>
</atlassian-plugin>
Each plugin has a plugin key which must be unique to the plugin. We suggest using the Java convention of reversing your domain name in order to ensure your key is unique. Each module has a module key which need only be unique within the plugin it is defined.
Sometimes you will need to uniquely identify a module - you do this with the module complete key. A module with key fred
in a plugin keyed as com.example.modules
will have a complete key of com.example.modules:fred
All plugin modules have a class attribute, which tells the plugin manager which Java class it should instantiate when loading the module. What class you should provide depends on the module type. For example, theme, layout and colour-scheme modules can use classes already provided in Confluence (so you can write a theme pack without any Java code), but for macro and listener modules you need to write your own implementing class and include it in your plugin.
Java Classes
Because the plugin is a JAR that is dropped into the Confluence classpath, all Java classes contained within the JAR become a part of the Confluence application. You can include as many classes as you like, and have them interact with each other. Obviously, it's important to follow the Java package naming conventions to ensure your plugin's classes do not conflict with Confluence classes, or other plugins.
If you are writing a Java implementation of a plugin module (see the description of the module's class
attribute above), you will be interested in Accessing Confluence Components From Plugin Modules.
You might also want to see the Confluence Developer FAQ, which answers particular questions that have come up from users regarding coding within Confluence.
Plugin and Module Resources
Resources are non-Java files that a plugin may need in order to operate. Examples of possible resources might be:
- A velocity file used to generate HTML for a macro or layout plugin module
- A CSS file required by a theme layout plugin module
- An image referenced from within a layout plugin module
- A macro help file
- A localisation property file
Resource definitions look like this. They can be either a part of the plugin, or part of a particular plugin module:
<!-- A resource has a type, a name and a location. The resource definition maps -->
<!-- some arbitrary resource name to where that resource would be located in -->
<!-- the server's classpath -->
<resource type="velocity" name="template" location="com/example/plugin/template.vm"/>
<!-- For the localisation property file below, it must be named exampleplugin.properties -->
<!-- located under the resources folder -->
<resource type="i18n" name="i18n" location="resources/exampleplugin" />
<!-- Resources may contain arbitrary key/value pairs -->
<resource type="download" name="style.css" location="com/example/plugin/style.css">
<property key="content-type" value="text/css"/>
</resource>
The name of the resource defines how the plugin module can locate a particular resource. The type of a resource tells the module how that resource can be used. A module can look for resources of a certain type or name: for example the layout
plugin required that its help file is a file of type velocity
and name help
.
The location of a resource tells the plugin where the resource can be found in the jar file (resources are loaded by Java's classpath resource-loader). The full path to the file - without a leading slash - is required.
The simplest kind of resource, supported with all plugin module types, is of type download
, which makes a resource available for download from the Confluence server at a particular URL. See: Downloadable Plugin Resources.
Plugin Self-Configuration
Plugins can specify internal links within Confluence to configure themselves. This is useful where your plugin requires any configuration or user specific settings to work. For example, the Google Maps plugin requires a Google API Key from Google (which needs to be configured on each server) before it will work properly.
- Configuration links will most often point to XWork plugin modules within the plugin itself
- Configuration links can be provided for a whole plugin and/or for any module within a plugin
- Configuration links are relative to the Confluence application
Plugin configuration - to add a configuration link for the whole plugin, place a single param
element with the name configure.url
within the plugin-info
element at the top of the plugin descriptor:
<plugin-info>
<description>A macro which displays Google maps within a Confluence page.</description>
<vendor name="Atlassian Software Systems Pty Ltd" url="http://www.atlassian.com/"/>
<version>0.1</version>
<param name="configure.url">/admin/plugins/gmaps/configurePlugin.action</param>
</plugin-info>
Plugin module configuration - to add a configuration link for a single module, place the same param
element with the name configure.url
within the descriptor
element for that module:
<macro name="gmap" class="com.atlassian.confluence.ext.gmaps.GmapsMacro" key="gmap">
<description>The individual map macro.</description>
<param name="configure.url">/admin/plugins/gmaps/configureMacro.action</param>
</macro>
Here is an image showing where the Configure
links appear for both a plugin and an individual module:
