Tips on writing an RHQ Plugin
Sometimes one of the most difficult things to do as a plugin developer is to bring some semblance, some order to the wide variety of features and functions that exist in software today. What may seem like a perfectly logical way to capture that information to you may seem utterly backwards to someone else. And the reason should come as no surprise – we all think about things differently.
So what’s the trick to developing a single solution that is going to make everyone happy? Well, unfortunately, there isn’t one. However, there are some steps that you can take to try and mitigate this mismatch of thought, and keep most satisfied in the end.
Do your research, and seek input from others
This is crucial. Do not let developer-ego get in the way of your plugin reaching a large audience quickly. Designing and developing an RHQ plugin is not some esoteric task in coming up with the purest design or most fascinatingly abstract model; it should be one of pragmatism. You need to balance the desire to come up with an infinitely generic solution with one that accurately models the system for as many realistic uses of it as possible.
Sometimes the software you’re writing your plugin for has only a small number of options. In this case, you might get lucky and be able to find the information you’re looking for by doing your homework and perusing the product’s documentation. For instance, some application might have a completely “portable installation” where all of its executables, configuration files, temporary files, etc are placed beneath a single root directory. Here, you might only need to prompt the user for that root in order to automatically discover everything else about it in a simple, consistent way.
However, there are plenty of pieces of software out there that aren’t so cut-and-dry. If they have tons of startup options, or have dozens of ways of being installed and configured, you might need to sleuth around public message boards or other help sites in order to gain the necessary insight to help focus your development efforts. For example, some application servers have a variety of ways you can configure how they bind to your network adapters: one or two different command line options, a configuration file parameter, a runtime service, etc. Supporting all of these, in all of their various flavors, across all the various versions of the software might be overly time-consuming and probably not even worth it for the first version of your plugin. Instead, focusing your development on the 1 or 2 most common ways will give you an excellent return on your time investment, helping to support a large number of clients now, while not necessarily discounting support for the less common bind methods in the future. Which brings me to my next point…
Design for today, not tomorrow
Software-based systems are changing all the time. Most often this is through a series of patches or, of greater consequence, an upgrade to a new minor or major version. If you attempt to write solutions to handle every conceivable modification to the software your plugin is supposed to be managing, this moving target will cause your design to remain in a constant state of flux and your plugin to remain unfinished…indefinitely.
For example, if you’re writing a plugin for JBoss AS 4.x, stick to the features and functions of JBoss AS 4.x – don’t try to design your plugin to support what may or may not be in, say, JBoss AS 5.x. Quite often different major versions of products will not only look substantially different but also operate quite differently behind the scenes:
- each version might support different specs – thus requiring different plugin code to support different service contracts
- configuration file structure and/or content is changed – thus requiring new parsing code and a different interpretation of it
- service deprecation, interface changes, and new features – thus requiring the handling code to be denser and more complex to handle the various permutations
So you really need to make the conscious decision from the start to support a specific version range of the software in question; doing this will help keep the plugin code smaller, more maintainable, and will – most importantly – get it done faster. If you absolutely need to support a wide range, but the different versions of the software are so disparate you can’t quickly or easily find a reasonable common ground, there is nothing stopping you from writing two plugins. Each one would manage and monitor a mutually exclusive slice of the entire range. For instance, to complement the example above, you would write your JBoss AS 4.x plugin separately from your JBoss AS 5.x plugin.
The key thing about all of this is to find that healthy balance between form and function that will help you get your plugin out of development and into your (or your customers’) RHQ infrastructure quickly.