Plugins 2.0: The Overview


Published on

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 Brown

Key Takeaways:

* In-depth look at plugins 2
* How-tos and code samples

Published in: Technology, Art & Photos
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Plugins 2.0: The Overview

  1. 1. Plugins 2.0: The overview Don Brown, Atlassian
  2. 2. Confluence Team Hosted
  3. 3. JIRA Studio
  4. 4. Why do we need a new plugin framework?
  5. 5. One feature * five products = Dashboard
  6. 6. Multiple teams across the globe Gdańsk, Poland San Francisco, USA Kuala Lumpur, Malaysia Sydney, Australia
  7. 7. Plugin development slow   Write plugin code   Build plugin   Copy plugin to WEB-INF/lib   Start app   Discover bug   Wash, rinse, repeat
  8. 8. Inconsistency between products . . . Constructor injection? Setter injection? Pico? Spring?
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. Which products?   Crowd 1.5 ✔   FishEye 1.5 ✔   Crucible 1.5 ✔   Confluence 2.10 ✔   JIRA 4.0   Bamboo 2.3
  13. 13. 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
  14. 14. Goal - Minimal OSGi required   Can we scale the learning curve to keep the easy plugins easy?
  15. 15. 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
  16. 16. 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
  17. 17. Dynamic deployment = faster dev cycle   Without OSGi   With OSGi 1.  Code 1.  Code 2.  Compile 2.  Build and push to 3.  Copy to WEB-INF/lib running web 4.  Restart application application 5.  Test in browser 3.  Test in browser . . . from code to browser in one or two seconds
  18. 18. Standard plugin modules   Servlet   Component o  servlet o  component o  servlet-filter o  component-import o  servlet-listener   Web Items o  servlet-context- o  web-item param o  web-section   Misc o  module-type o  web-resource
  19. 19. Sandboxed plugins
  20. 20. DEMO: Using Atlassian Plugins
  21. 21. Plugins architecture
  22. 22. Plugin descriptor atlassian-plugin.xml   <atlassian-plugin key=quot;; name=quot;Example Plugin” plugins-version=“2”> <plugin-info> <description>A sample plugin</description> <version>1.0</version> </plugin-info> <servlet key=”testquot; name=”Test Servletquot; class=quot;;> <description>An example servlet</description> </servlet> </atlassian-plugin>
  23. 23. Plugin descriptor - Hidden OSGi atlassian-plugin.xml   <atlassian-plugin key=quot;; name=quot;Example Plugin” plugins-version=“2”> … <component key=”myComponentquot; class=quot;” public=“true”> <interface></interface> </component> <component-import key=”otherComponentquot; interface=quot;” /> </atlassian-plugin>
  24. 24. Plugin descriptor - Hidden OSGi Generates   atlassian-plugin-spring.xml <beans …> <bean id=“myComponent class=“” /> <osgi:service id=“myComponent_service” ref=“myComponent” interface=“” /> <osgi:reference id=“otherComponentquot; interface=quot;” /> </beans>
  25. 25. 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
  26. 26. Plugins 2 showcase
  27. 27. Atlassian Gadgets
  28. 28. Shared Access Layer (SAL)   Plugin upgrade framework   Plugin settings   Job scheduling   i18n   Search   HTTP calls . . . and much more
  29. 29. Atlassian REST Module Type   Implemented as a GET rest/name/1.0/bob dynamic module type {   Uses JAX-RS quot;firstNamequot;:”Bobquot;,   Can be extended quot;lastNamequot;:quot;Smithquot; by other plugins to add new data } mappers
  30. 30. Plugin Exchange Client Uses REST plugin type for JSON, XML, and HTML
  31. 31. Confluence Widget Connector Widget types extendable via plugins
  32. 32. 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
  33. 33. Join the fun!
  34. 34. Questions