plugins 2.0: the overview

Post on 31-Oct-2014

7 Views

Category:

Technology

2 Downloads

Preview:

Click to see full reader

DESCRIPTION

Plugins have evolved in the past year, and the new plugin architecture will be incorporated in all products in 2009. This session dives into the detail of the new plugins system, guides developers on the best techniques and approaches and explores how the architecture will evolve further.Atlassian Speaker: Don BrownKey Takeaways: * In-depth look at plugins 2 * How-tos and code samples

TRANSCRIPT

Don Brown, Atlassian

Plugins 2.0: The overview

Confluence Team Hosted

JIRA Studio

Why do we need a new plugin framework?

One feature * five products =

Dashboard

Multiple teams across the globe

Gdańsk, Poland San Francisco, USA

Kuala Lumpur, Malaysia Sydney, Australia

Plugin development slow

  Write plugin code   Build plugin   Copy plugin to

WEB-INF/lib   Start app   Discover bug   Wash, rinse, repeat

Inconsistency between products

. . . 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% compatible o WEB-INF/lib o Confluenceʼs dynamic plugins

  Version 2 (OSGi-based) plugins o Compatibility varies by product

Which products?

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

OSGi in one slide  Bundles contain code,

configuration, manifest metadata

 Runtime dependencies at Java package, service, and bundle levels

 Supports multiple versions of code

 Can share dynamic service objects

  Lifecycle: install, resolve, active, uninstall

Goal - Minimal OSGi required

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

Each team can “own” a bundle   Only JAX-RS exposed

  Complete freedom to switch to another JAX-RS implementation

  Can run multiple versions of the bundle side-by-side

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 OSGi

1.  Code 2.  Compile 3.  Copy to WEB-INF/lib 4.  Restart application 5.  Test in browser

  With OSGi 1.  Code 2.  Build and push to

running web application

3.  Test in browser

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

Standard plugin modules

  Servlet o  servlet o  servlet-filter o  servlet-listener o  servlet-context-

param

  Component o  component o  component-import

  Web Items o web-item o web-section

  Misc o module-type o 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 OSGi  atlassian-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 OSGi  Generates 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 OSGi o Moderate - OSGi

via plugin descriptor o Complex - OSGi

via Spring XML directly

Plugins 2 showcase

Atlassian Gadgets

Shared Access Layer (SAL)

  Plugin upgrade framework

  Plugin settings   Job scheduling   i18n   Search   HTTP calls . . . and much more

Atlassian REST Module Type

  Implemented as a dynamic module type

  Uses JAX-RS   Can be extended

by other plugins to add new data mappers

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 2   Streams 2   Confluence Repository

Client   Template renderer   Team Hosted plugins   Studio plugins   All Crucible and

FishEye plugins   All OSGi bundles

Join the fun!

Questions

top related