Can ScriptRunner be used as an alternative to standard plugin development?

[Al Johnson]

Hi,

I've been tasked with evaluating whether or not ScriptRunner (for Confluence) could be used to add functionality and extend Confluence in place of the regular plugin development method.  From what I can see, yes, but only in a limited way.  With SR, I can create some of the module types such as Web Items, Web Sections, Web Resources, REST endpoints, etc., but only on an individual basis whereas a single plugin could incorporate many of these web modules and more in a self-contained package (jar).  To migrate a moderately complex plugin consisting of several modules would require one to create each of those modules through SR on their individual screens, and if that could be done, great.  But, once you have several plugin code migrated to SR, I'm guessing it could get messy trying to remember which modules and scripts work as a group.  Also, SR, does not support all the module types available to plugins, so that would be another drawback.

Sorry if this is an unusual question and thanks in advance for your response.

Al

[JamieA]

People use script plugins to draw together the various components that make up a particular "solution". They contain the code plus any necessary configuration. 

Yes you are right in that not every area is covered by a simpler scripting interface, but in that case you can also include any plugin extension point in a script plugin, in the normal way. You can write those extensions in groovy or java as you choose.

When you get to require quite complex plugins, classloader problems can cause diminishing returns and you may as well write a regular java plugin. It all depends whether the dev speed advantage is worthwhile to you or not.