Hi,
at the moment we are working on a plugin, that should work for JIRA and Confluence. It is a plugin system 2 plugin. The first idea was, to develop a ref-app plugin, and depending on the SAL functionality. The challenge now is, some parts of the functionality can not be developed with ref-app. As far as it looks like, round about 80% of the plugin is generic and the rest have to be developed individual for Confluence and JIRA (and perhaps other Atlassian products later on).
I see three possible ways to do this, but perhaps I am missing something:
1) The core functionality is developed in a ref-app plugin. And the plugin defines his own module-type. In addition there is a special plugin for JIRA and Confluence each, which extends the ref-app plugin, by implementing the module-type. But with this solution the customer would have to install two plugins.
2) The core functionality is developed in a ref-app plugin, but will not be deployed on its own. Instead it is included as maven dependency in the application specific plugins and get extended there. The advantage is, the core plugin is testable as ref-app plugin. But I am not sure what happens, when a ref-app plugin is included as dependency. Especially if there could be version conflicts.
3) The core functionality of the core plugin have to be totally decoupled from the Atlassian Plugin system, not using any Atlassian libraries. So it can be included as a plain java library into the product specific plugins. In taht case we would need to write some kind of wrappers, as the core plugin uses a lot of SAL functions.
Is there any best practise for developing such kind of "universal plugins"? I am missing something? Your help would really be appreciated.
Regrads,
Alexander
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.