JIRA 4.0 : Differences between Plugins1 and Plugins2
This page last changed on Sep 28, 2009 by rosie@atlassian.com.
On this page: IntroductionPlugins FrameworkJIRA uses a library called the Atlassian Plugin Framework to manage its plugins. This library is developed separately to JIRA (it is a shared library used by all the Atlassian products) and therefore has its own versioning. For example JIRA v4.0 uses Plugin Framework v2.3, JIRA v3.13 uses Plugin Framework v0.23. Plugin versionsBefore Plugins Framework v2 (JIRA v3.13 and earlier), plugins were installed in JIRA by adding the plugin JAR file to JIRA's classpath (WEB-INF/lib). This style of plugin is referred to as "Plugins1". Plugins Framework v2 (JIRA v4.0 and higher) introduced a new way to install plugins. Plugins can be installed in JIRA's "installed-plugins" directory from where they will be installed and managed by an OSGi Container. This type of plugin is referred to as "Plugins2". It is important to note that Plugins2 is not considered a replacement for Plugins1. Each provides some advantages and disadvantages. Plugin developers should consider their particular plugin, and choose which plugin type to use accordingly. Plugins1Plugins1 was the original way to install and manage plugins. In JIRA, these are installed by placing the plugin JAR in your WEB-INF/lib/ directory. Plugins2Plugins2 plugins are not installed in the core ClassLoader. They are installed and managed by an OSGi container. This means each Plugin has its own child ClassLoader that loads the classes of that plugin. By default, plugins cannot use the classes of another plugin. However, one plugin can explicitly export some of its packages, and then other plugins can import these dependencies. In this way, the interdependencies can be much better managed. In addition, a Plugins2 plugin can create its own custom extension points. Effectively, you can allow plugin points for your plugin. Development and InstallationConfigurationThe JAR file for a Plugins1 plugin looks exactly the same as one for Plugins2 with one difference in the configuration file. <atlassian-plugin key="${atlassian.plugin.key}" name="${project.name}" plugins-version="2"> InstallationA Plugins1 plugin must be on the application classpath, and therefore is installed in WEB-INF/lib. Dependency InjectionThe ContainerJIRA uses Pico Container to manage Dependency Injection in its core classes and in Plugins1 classes. On the other hand, Dependency Injection in Plugins2 plugins is not managed directly from JIRA, it is done in the Plugin Framework. Also, JIRA does not make all of its internal components available to the Plugin Framework. Some are considered unsuitable for plugin developers to use as they really should only be used by core systems. ComponentsComponents in JIRA can considered as the "services" in a Service Oriented Architecture. They are the Dependency Objects that can be Dependency Injected into other objects. Plugins1 ComponentsIf a Plugins1 plugin declares a component, then that component is added to JIRA's core dependency injection container, and will be available as a dependency to any other plugin. Plugins2 ComponentsIf a Plugins2 plugin declares a component, then by default this component is "private". Other classes in this plugin will be able to get the component injected in them, but other plugins will not. Java packagesOSGi exports and imports dependencies based on Java packages. Only one ClassLoader can export classes from any given package. Under Plugins2 this means it is even more important to not duplicate package names of core JIRA classes, or other plugins. Of particular interest is the Webwork plugin module. <webwork1 key="qquserissue" name="Quick Create User Issue" class="java.lang.Object"> <actions> <action name="com.atlassian.jira.toolkit.action.QuickCreateUserIssueAction" alias="QuickCreateUserIssue"> <view name="createuserissue">/templates/quickcreateuser.vm</view> </action> </actions> </webwork1> |
![]() |
Document generated by Confluence on Oct 06, 2009 00:31 |