"... so I put a plugin module in your plugin, so you can write plugins for your plugins." 1

This presentation is publicly available on Prezi. Try not to get motion sick.

I have sort of a hunch – not really backed up by any concrete data, just a feeling – about the current "state of the art" in plugin development best practices, specifically with respect to componentization and reuse:

  • I figure most plugin developers have used the Component Import module type, to use important functionality provided by the host application (such as services in SAL).
  • I'd guess that fewer developers have used Component Import to use components provided by another installed plugin (or at least not knowingly), or have used the Component module type to publicly export an interface for the consumption of other plugins. But not too few.
  • However, I'd guess that very few developers have used the Module Type module type, to introduce new extension points into the plugin framework (and if you have, I'd love to know!).

There are a few examples where we've used the Module Type module type 2 internally, that many plugin developers in the community have happily used without really knowing (or needing to know) the implementation details. For example, the REST module type (which you'd reference in your plugin descriptor with a <rest key="..."/> module descriptor entry in your atlassian-plugin.xml): that's not actually provided by the plugins framework directly; instead it's provided by the REST plugin via a Module Type module type. The REST plugin is bundled with the products, so that other plugins can use the module type it exposes.

For "fun," I wrote a UPM Tab plugin module type (again, using the Module Type module type), so that developers can extend the UPM with new tabs. This is similar in concept to Web Items and Web Panels, in the sense that it permits a seamless UI integration. The difference, of course, is that here a plugin is extending another plugin.

So my plan is to squeeze as much detail about how I did that, into a five minute lightning talk, so that everybody can write pluggable plugins.




1 Seriously, it's like that.
2 I can tell how awesome it's going to be, talking conversationally about the "Module Type module type."

  • No labels

6 Comments

  1. Dan Hardiker

    You should check out my post about AtlasCamp 2008: AtlasCamp + Atlassian Plugins v2. We've been making pluggable plugins for a while - in fact the Plugin Licensing stuff we'll be showing off allows you to registerer licensed code, and put in additional license restrictions using this method.

    It should be noted that we've found, in some more complex cases, that it's better to hand write the Spring xml - especially when you want loose linking; or when you get load order problems (loading plugin using the module before loading plugin providing the module, or reinstalling the plugin providing the module while living the using plugins there).

    1. Dan Rosen [Atlassian]

      The Plugin Licensing stuff we'll be showing off allows you to registerer licensed code ... using this method.

      Cool! Looking forward to seeing what you've got.

      It should be noted that we've found, in some more complex cases, that it's better to hand write the Spring xml - especially when you want loose linking ...

      Can you give an example where using <module-type> yielded coupling that was too tight? I'm not picturing it.

      ... or when you get load order problems (loading plugin using the module before loading plugin providing the module ...)

      This shouldn't be a problem AFAIK. I'm pretty sure that given plugin P dependent on module M, the plugin framework is smart enough to defer loading P until M is available. It doesn't go about this in quite the most elegant way you could imagine – it simply keeps retrying P until 60 seconds have passed – but in practical terms it seems to work fine.

      Reinstallation, on the other hand, I'm less sure about.

      1. Dan Hardiker

        Can you give an example where using <module-type> yielded coupling that was too tight? I'm not picturing it.

        Plugin A defines Module B as an interface which Plugin B package-imports, implements and defines in it's atlassian-plugin.xml. Plugin B will not start if Plugin A is not install - even if the module is not core to the Plugin B's functionality.

        Last tested almost 2 years ago mind you!

        I'm pretty sure that given plugin P dependent on module M, the plugin framework is smart enough to defer loading P until M is available.

        I know the theory (in fact I suggested it in the first place! PLUG-200); just found in practice it to be less reliable than desired. Once all the plugins are enabled it's generally stable though.

        We've had all sorts of problems with doing it in 2.10, 3.0 and 3.1 ... can't say we've tried too much with 3.2 and 3.3 though.

        I even have an example which can fail if you turn debugging on as timeouts get hit! I know that particular bug has been fixed in newer versions, but we're stuck in this case with what they have in production.

  2. jonathan doklovic

    I'd guess that very few developers have used the Module Type module type, to introduce new extension points into the plugin framework (and if you have, I'd love to know!).

    The Sysbliss AMF Server Plugin adds a module type to allow other plugins to define service classes to be exposed to flash.

    Also, I completely refactored the Bamboo Tagger Plugin into a whole new plugin called the Bamboo Repo-Tools plugin which added module types for SCM Taggers and Branchers and provided implementations of these for CVS, SVN, and Perforce. The thought was that taggers and branchers should be pluggable.

    Unfortunately, this was never release due to the fact that a core class in Bamboo VariableSubstitutionBean cannot be used within a V2 plugin. (sad)

    1. Dan Rosen [Atlassian]

      Unfortunately, this was never release due to the fact that a core class in Bamboo VariableSubstitutionBean cannot be used within a V2 plugin. (sad)

      I remember you wrestling with this, not long after I started working here... Do you know if there's an issue filed anywhere on that? I'd really like to see this working.

      1. jonathan doklovic

        I exchanged emails with Chai about this and apparently we never logged an issue and never got it resolved.
        The emails have some good info in them though...

        Just logged an issue and included all the pertinent info from the emails. http://jira.atlassian.com/browse/BAM-6969