Upload
atlassian
View
5
Download
2
Embed Size (px)
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
Citation preview
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