2 Replies Latest reply on Feb 28, 2012 7:01 AM by Ryan Rutan

    What are your best practices for developing a plugin that supports multiple Jive versions?



      I am currently in the process of making a Jive 4.5 plugin support Jive 5 and I wanted to know what policies do you employ in order to properly (and efficiently) develop plugins that support two (or more) Jive versions?


      The first obstacle is that there is a different maven archetypes for Jive 4.5 plugins and Jive 5 plugins, forcing you to have two different plugin directories.


      I'm looking for any advice especially areas I haven't thought of but here are questions I already started to contemplate:

      • Artifact separation, what combination of the following is best:
        1. Differ in group id (e.g. mycompany.jive4/mycompany.jive5)
        2. Differ in artifact id (e.g. plugin4/plugin5)
        3. Differ by version (even keeping group and artifact id the same but having a different major version for each Jive version)
      • How to avoid duplicate java/web code (At first glance suggestions 3 looks the most versatile but also with the most effort)
        1. Using SVN externals
        2. Using a soft link (File system) between the source directories (as to have only one physical directory)
        3. Core of the plugin developed in a separate library (jar) project which is then included in both plugin projects
      • How to avoid duplicate configuration (spring, struts, plugin) -- Basically like the code only it's a tad less feasible to have the same configuration (since it's more dependent on the target Jive version)


      Edit: Typo.

        • Re: What are your best practices for developing a plugin that supports multiple Jive versions?

          Alright so I've been tackling this today and I wanted to share what I gathered so far:

          Regarding maven artifact I choose to go with separation by version (and only that), I deemed this as the most logical choice among the three, if/when I am proven wrong or have more insight I will update.


          As for avoiding duplicate code I started going with choice number three, but then realized the very obvious: Even the core artifact has to declare it's dependency on some (major) version of Jive.

          So to counter that I thought of three things:

          1. Abandon this approach (Shared core)
          2. Depend on the lower Jive version (i.e. 4.5) and realize the plugin is broken due to API changes partially in compile time partially in runtime.
          3. Have the core artifact independent of any Jive version but build your own layer of separation. Let the core depend on it and have one adapter for each (major) Jive version.

          I immediately eliminated number 2, and while 3 is a decent option the added up overhead is just not worth it (In my option, for my use case). To conclude I have decided to use a filesystem symbolic link I will let you know how that works out.


          About configuration I went with complete separation, again this seemed as the most logical choice to me, if/when I am proven wrong I will update.


          Please don't hesitate to give any remarks or ask any questions.