We recently decided it would be useful to develop a RAD plug-in that would allow developers to log time against tasks more simply. I'm not going to detail all the steps involved, or indeed provide much information regarding the actual plug-in we developed, but I thought it would be useful to note down some of the issues I hit, and thoughts I had along the way.
RAD6 vs RAD7
We have some developers using RAD6 and others using RAD7 (and some other staff that use neither of these), and the initial decision was to develop the plug-in for RAD7. This was the environment that I was predominantly using and the thought was that most staff would eventually upgrade.
In hindsight this might not have been a great decision. After getting the RAD7 version working we needed to try to get all staff using the new system (the old timesheet system had been finished with), and the developers writing Websphere Commerce applications were finding it impossible to upgrade RAD for the time being. Hence we had to back port the existing plug-in to RAD6.
Thinking that this would be a relatively trivial task I started by changing my target environment and seeing what, if anything, in the existing code would break.
It looked as though there were only a couple of things - code relying on the web browser framework and some of the listeners. I simply created a couple of new plug-in projects and encapsulated the platform specific logic into these, then when the feature was built I could reference the correct one to build the plug-in.
Testing this failed immediately with an error stating that execution environment and runtime environment did not match. This caused me quite a bit of grief... I tried changing the execution environment stipulation in the plugin.xml down from Java5 - to Java1.4 - to Java1.3, still the same error. Having eliminated this as the cause of the error I tried to find out exactly what version of java RAD6 was using. It turns out that a JRE is bundled into RAD and this is not a standard JRE, but is a flavour of Java 1.4. Immediately this caused me another problem as I had used Java5 in my RAD7 plugin and had also utilised some of the benfits of this such as generics and enums. After changing all the code down to match the JRE stipulation, testing the plug-in failed yet again! This time it turned out that the structure of the plugin was causing a problem and RAD6 was not correctly reading the MANIFEST file. The only solution I could find to this was to remove the MANIFEST file and code the equivalent configuration into the plugin.xml.
End result is that we now have a completely separate set of plug-in projects to support the RAD6 version. So much for code reuse!
Plug-in activator
The structure of the plug-in was such that I wanted the UI and business object model to be separated from the back-end time reporting repository and connectors to this. The idea being that although we would initially be using Bugzilla as the repository if we found something better, then as long as I could write a new connector, to retrieve and update the information, then the rest of the plug-in would not need to be touched.
In order to do this I separated the task repository connection into a separate plug-in and then planned to get it to push an instance of the repository into the main business object model activator at startup of the bundle. The idea being that the main business object model activator only needed to know about an interface to the repository, and the actual implementation would be sourced at runtime. However, this has a slight issue - the repository plug-in would only be activated when one of it's classes was loaded, and none of it's classes would be loaded because there was no direct reference.
I tried to force the startup process of the activator from one of the other plug-ins, but this simply caused more issues, and in the end had to simply reference the bugzilla repository class direct ly.
This is not an ideal solution, but seeing as the number of times this is likely to occur is pretty small I decided it wouldn't be too big a problem. Thinking about it again now I wonder if there is a way of forcing the load of the plug-in when RAD is started? If anyone knows then I would definitely be interested!
Update site and feature
I thought this was worth a mention because this has caused some confusion for me.
I've had several occasions where, after appearing to get the plug-in working, I've tried to deploy to a test environment via the update site only to find that it still doesn't work properly. Some of these issues have been related to JRE/environment settings etc as detailed above, but some have come from the latest code not building correctly - or the update not picking up the latest code. This seems to have been much more of an issue for the RAD6 plug-in, but it seems that the best way around any issues has been to always increase the version number when building and deploying to the update site. Even if this is still within testing cycles.
Making the plug-in available to a wider audience
As well as the developers we also have a number of project managers/admin staff that require access to the plug-in. I've thought of quite a few ways of doing this - create an RCP, create and RAP... And then there's the simple approach which we are using as a short term alternative.
I've installed a vanilla version of Eclipse 3.2.2 (this is the base version of Eclipse that RAD7 is built on) on the relevant machines, and installed my RAD7 version of the plug-in onto this - there's no dependency on any RAD libraries. Simple!
At some point I will go back to the RCP/RAP alternatives as this should give a cleaner solution - but for now everyone can work happily.
