Highlights of this Release:

Haven't used the Atlassian Plugin Framework 2 yet?
Take a look at the development platform documentation and the Plugin Framework documentation.

Comments, Requests and Feedback
We would love your feedback. Please log your requests, bug reports and comments in our issue tracker.

Framework for New Atlassian Development

The Atlassian Plugin Framework 2.2 provides new features and improvements required by several Atlassian projects currently under development. While the plugins described below are not yet available, the Atlassian Plugin Framework is now ready to support them.

• Unified Plugin Manager plugin — Still in the planning stage, the UPM will enable uniform management of plugins across Atlassian applications. It will interact with the new plugin repository also under development.
• Atlassian Gadgets — Development of a new cross-application dashboard is well under way, based on Google Gadgets and OpenSocial and built with the Atlassian Plugin Framework 2.2. Atlassian Gadgets will allow applications to publish gadgets to each other and display them on dynamic, drag-and-drop dashboards.
• OAuth plugin — This plugin will support the OAuth authentication protocol, allowing your plugin to accept requests for OAuth authentication from external applications.
• REST module plugin — Developers will be able to use the REST module type to create plugin points easily in compliant Atlassian applications. The module type allows you to expose services and resources as REST end points. In this way, you can create and use REST end points consistently across Atlassian applications. The plugin also makes it easier to develop cross-application plugins i.e. plugins which work in more than one application.

Dynamic Plugin Support

With this release, the Atlassian Plugin Framework supports dynamic plugins for non-dynamic module descriptors. This allows the Atlassian applications to support dynamic plugin installation, without requiring a restart of the application.

Confluence already supports dynamic plugin loading. Other applications such as JIRA will support it future releases.

Application-Specific Modules

Cross-application plugins can now contain modules that are only enabled for specific applications. Adding the application attribute to a module descriptor in atlassian-plugin.xml will ensure that it is only enabled for the particular application that it works with. Module descriptors without an application attribute are loaded in all applications. This allows you to write cross-application plugins, sharing common Java code, that can be deployed correctly onto multiple applications.

For example, you might have a servlet plugin with individual web items for each potential application.

<atlassian-plugin name="Hello World Plugin" key="example.plugin.helloworld" pluginsVersion="2">
<plugin-info>
<description>A basic web item module test</description>
<vendor name="Atlassian Software Systems" url="http://www.atlassian.com"/>
<version>1.0</version>
</plugin-info>

<web-item key="google_home" name="Google Home" section="system.user/example1" weight="10" application="confluence">
<description key="item.google.home.desc">Simple link to google.com.</description>
<label key="item.google.home.label" />
<link linkId="google_home">http://google.com</link>
</web-item>

<web-item key="google_home" name="Google Home" section="system.user.navigation.bar/example1" weight="10" application="jira">
<description key="item.google.home.desc">Simple link to google.com.</description>
<label key="item.google.home.label" />
<link linkId="google_home">http://google.com</link>
</web-item>

<servlet name="Hello World Servlet" key="helloWorld" class="com.example.myplugins.helloworld.HelloWorldServlet">
<description>Says Hello World, Australia or your name.</description>
<url-pattern>/helloworld</url-pattern>
<init-param>
<param-name>defaultName</param-name>
<param-value>Australia</param-value>
</init-param>
</servlet> 
</atlassian-plugin>

Shared Access Layer (SAL) 2.0

Version 2.2 of the Atlassian Plugin Framework supports Shared Access Layer (SAL) 2.0. This release of SAL provides an API to retrieve the current user's locale, other internationalisation improvements, user authentication via OAuth and fixes as shown in the SAL 2.0 Release Notes.

Faster Startup Time

Performance improvements in the Atlassian Plugin Framework 2.2 will reduce the time an application takes to start.

• Optimised package scanning.
• Caching of transformed plugins.
• Bypassing of Spring for host component references.

Batching of Web Resources

The Atlassian Plugin Framework now supports batching of web resources, so that multiple plugin web resources can be served in one request. It is now possible to have your web-resource modules served either as individual files (as before) or combined into a single batch containing all of the CSS or JavaScript files together. Batching reduces the number of HTTP requests that web browsers need to make to load a web page. This is one of the easiest ways to speed things up for users.

Here is an example atlassian-plugin.xml file containing two resources:

<atlassian-plugin name="Hello World Resource" key="example.plugin.helloworld" pluginsVersion="2">
<plugin-info>
<description>A basic web resource module test</description>
<vendor name="Atlassian Software Systems" url="http://www.atlassian.com"/>
<version>1.0</version>
</plugin-info>

<web-resource key="my-resources" name="My Plugin Resources" >
<resource type="download" name="scriptaculous.js" location="myplugin/js/scriptaculous.js" />
<resource type="download" name="effects.js" location="myplugin/js/effects.js" />
</web-resource>
</atlassian-plugin>

Previously, the framework would have served the resources individually as two separate requests:

http://localhost:8080/confluence/download/resources/mypluginkey:my-resources/scriptaculous.js
http://localhost:8080/confluence/download/resources/mypluginkey:my-resources/effects.js

With batching, the framework will serve the resources together in one request:

http://localhost:8080/confluence/download/batch/js/mypluginkey:my-resources/BATCHNAME.js

Note that in most cases you do not need to change your existing plugins' XML descriptors to enable batching. In the above example, the atlassian-plugin.xml file remains unchanged.

Handy tips:

• If you have defined a source parameter in the atlassian-plugin.xml, you may need to make a change. Web resources are not batched if the source parameter in the atlassian-plugin.xml is set to webContext. Such web resources include both static and dynamic resources. For static resources, we recommend that you update the source parameter to webContextStatic.
• You can turn off batching application-wide for debugging purposes via a system property: plugin.webresource.batching.off=true
• To turn off batching of individual web resources, set the new batch parameter to false on the web resource in the atlassian-plugin.xml.

Improved Validation and Error Messages

Enhanced validation of module descriptors and clearer error messages make plugin development easier.

• The plugin framework now has an XML validation library based on ISO Schematron-based, making it easier to validate a module descriptor in atlassian-plugin.xml or any dom4j node.
• We have improved the error handling, so that the framework will only log warnings if a plugin does not have an explicit Spring context header.
• The framework issues clearer error messages, such as when a descriptor tries to load classes in the init method.

Improved Package Export Behaviour

Packages from plugins are no longer exported by default. Interfaces from public components are exported automatically, i.e. if a public component is registered under an interface found in the bundle, the plugin framework exports it automatically. This change improves predictability and helps to avoid conflicts between plugins that embed the same libraries. See the problem definition.

If other plugins depend on your plugin and if you do not generate your own manifest, you will need to ensure that the necessary packages are exported.

• The quick fix is to add the following to your atlassian-plugin.xml:

  <plugin-info>
  ...
  <bundle-instructions>
  <Export-Package>*</Export-Package>
  </bundle-instructions>
  </plugin-info>
  

• The better solution is to export the necessary packages explicitly. See the <bundle-instructions> element.

Faster Plugin Development

A number of improvements in this release will help to speed up the plugin development process. In addition to the points already mentioned above, here are some more items to delight a jaded developer:

• With this release, the plugin framework will automatically reload any dependent plugins when the base plugin has been upgraded.
• Transformed module types like Component, Component Import, and Module Type now have proper module descriptors, so they show up in the UI as expected.
  Disabling these module types currently has no effect. We plan to fix this in a later release, via a unified plugin manager.
• During plugin development, you can now edit non-Java resource files and refresh your browser to see the changes immediately. The plugin framework allows plugin resources to be loaded from the file system during development. See Instant Loading of Plugin Resources.