Plugins 2.0: The Overview

Post on 22-Oct-2014

2784 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Talk given at Atlassian Summit 2009 discussing the Atlassian Plugins 2 framework and how to build plugins using it.

Transcript

Don Brown, Atlassian

Plugins 2.0: The overview

Confluence Team Hosted

QuickTime™ and a decompressor

are needed to see this picture.

JIRA Studio

QuickTime™ and a decompressor

are needed to see this picture.

Why do we need a new plugin framework?

One feature * five products =

Dashboard

Multiple teams across the globe

Gdańsk, PolandSan Francisco, USA

Kuala Lumpur, MalaysiaSydney, Australia

Plugin development slow

Write plugin codeBuild pluginCopy plugin to WEB-INF/libStart appDiscover bugWash, rinse, repeat

Inconsistency between products

QuickTime™ and a decompressor

are needed to see this picture.

QuickTime™ and a decompressor

are needed to see this picture.

QuickTime™ and a decompressor

are needed to see this picture.

QuickTime™ and a decompressor

are needed to see this picture.

. . . Constructor injection? Setter injection? Pico? Spring?

Plugins break on product upgrade

Plugins have unrestricted access to application classes, objects, and configuration

Broken plugins after a product upgrade make us look bad

Plugins 2 gives you. . .

Ability for plugins to depend on each other

Ability for plugins to define their own extension points

Consistent plugin development platform across products

Better insulation of plugins from product changes

Backwards compatibility

Version 1 plugins - 100% compatibleo WEB-INF/libo Confluence’s dynamic plugins

Version 2 (OSGi-based) pluginso Compatibility varies by product

Which products?

Crowd 1.5 FishEye 1.5 Crucible 1.5 Confluence 2.10 JIRA 4.0Bamboo 2.3

OSGi in one slide

Bundles contain code, configuration, manifest metadataRuntime dependencies at Java package, service, and bundle levelsSupports multiple versions of codeCan share dynamic service objectsLifecycle: install, resolve, active, uninstall

Goal - Minimal OSGi required

Can we scale the learning curve to keep the easy plugins easy?

Features written once

Example: OpenSocial-based dashboard as an OSGi plugin

Written and owned by San Francisco team

Contains UI, Shindig, internal services, SPI, and API

Dynamic deployment = faster dev cycle

Without OSGi1.Code2.Compile3.Copy to WEB-INF/lib4.Restart application5.Test in browser

With OSGi1.Code2.Build and push to

running web application

3.Test in browser

. . . from code to browser in one or two seconds

Standard plugin modules

Servleto servleto servlet-filtero servlet-listener

o servlet-context-param

Componento componento component-import

Web Itemso web-itemo web-section

Misco module-typeo web-resource

Sandboxed plugins

DEMO: Using Atlassian Plugins

Plugins architecture

Plugin descriptor

atlassian-plugin.xml

<atlassian-plugin key="com.xyz.example" name="Example Plugin” plugins-version=“2”> <plugin-info> <description>A sample plugin</description> <version>1.0</version> </plugin-info> <servlet key=”test" name=”Test Servlet" class="com.xyz.TestServlet"> <description>An example servlet</description> </servlet></atlassian-plugin>

Plugin descriptor - Hidden OSGiatlassian-plugin.xml

<atlassian-plugin key="com.xyz.example" name="Example Plugin” plugins-version=“2”> … <component key=”myComponent" class="com.xyz.MyComponent” public=“true”> <interface>com.xyz.Component</interface> </component>

<component-import key=”otherComponent" interface="com.abc.OtherComponent” />

</atlassian-plugin>

Plugin descriptor - Hidden OSGiGenerates atlassian-plugin-spring.xml

<beans …> <bean id=“myComponent class=“com.xyz.MyComponent” />

<osgi:service id=“myComponent_service” ref=“myComponent” interface=“com.xyz.Component” />

<osgi:reference id=“otherComponent" interface="com.abc.OtherComponent” /></beans>

Plugin to bundle process

Goal: Allow simple plugins with no OSGi knowledge

Three types of plugins:o Simple - no OSGio Moderate - OSGi via plugin descriptor

o Complex - OSGi via Spring XML directly

Plugins 2 showcase

Atlassian Gadgets

Shared Access Layer (SAL)

Plugin upgrade frameworkPlugin settingsJob schedulingi18n SearchHTTP calls

. . . and much more

Atlassian REST Module Type

Implemented as a dynamic module typeUses JAX-RSCan be extended by other plugins to add new data mappers

GET rest/name/1.0/bob

{ "firstName":”Bob", "lastName":"Smith"}

GET rest/name/1.0/bob

{ "firstName":”Bob", "lastName":"Smith"}

Plugin Exchange Client

Uses REST plugin type for JSON, XML, and HTML

Confluence Widget Connector

Widget types extendable via plugins

And many more. . .

Applinks 2Streams 2Confluence Repository ClientTemplate rendererTeam Hosted pluginsStudio pluginsAll Crucible and FishEye pluginsAll OSGi bundles

Join the fun!

Questions

top related