Updated my Eclipse Platform Extensions plug-in

Since Eclipse released 3.3/Europa I thought I should update my plug-in to match the release.  Plus there were a couple of people nagging nudging me to do it in the help forum.

There was not much changes in Eclipse that would affect the plug-in, but I decided that I won't cheese it and just increment the version number support on my plug-in and instead do some of the things I was meaning to learn, namely i18n of the plug-in.  That objective was completed successfully.

Here are some of the things I have learned while making this release.

• The current instructions for internationalizing Eclipse plug-ins using fragments is woefully out of date.  Eclipse 3.3 does not use fragments.xml I think they got rid of that requirement long ago and use MANIFEST.MF instead.
• When doing IVT of your plug-in with fragments, use the -clean parameter when starting up Eclipse.  I spent a lot of time trying to figure out why my plug-in did not switch to Japanese.
• Fragments do not automatically get built from the site, which is weird.  I have opened a bug report for it.
• Maven and Eclipse plug-in development is currently a lost cause (or at the very least a big pain).  I have removed the use of Maven from my plug-in, but I am keeping the Maven project layout since it seems more sane.

My attempts at Japanese and French are woefully laughable, maybe someone would release a patch for it.  Well I am trying to relearn Japanese and maybe Chinese as well as French.  So this provides me a way of doing this.

Along with this, I made some attempt to write yet another Ruby script to update my site.  I still don't like the libraries for Ruby, the language I can get around a bit.  Some findings I had were:

• I much prefer Java's import over the require.  At least whatever I import matches what I am going to use, rather than trying to figure out what the classes are in the module.
• There should be an ri that loads up the browser.  Or at least something that would update a core documentation like Perl does.
• They seriously need to work up on the consistency even in the Core libraries.  e.g. RUNIT::CUI vs RSS::RSS vs Sync_m.  Java's API naming may sometimes suck, but at least they suck relatively consistently with minor exceptions such as URL.
• Someone should refactor net/sftp to work like net/ftp or at the very least provide some useful and easy to find examples within their RDocs.  I had to Google to find an article that provides an example on how to do it (not really the best way of doing something, but the most efficient with the stuff out there).
• I wish the Maven repository was as good as Gem in terms of amount of JARs sometimes, thankfully there is a search engine for Mavenized JARs.

This is also my first attempt at using Windows Live Writer for my blog entry as Blogger's WYSIWYG editor is quite painful to use.

What I would look for in a requirements management tool

While looking through my RSS feeds I caught a glimpse of JRequisite. From the web site, it looks like a very far cry from any other requirements management tool you may have used at work (aside from Excel, Word and e-mails that is). That being said, it is still a good start. I wouldn't use it just yet, but it did get me to thinking what I would want in a requirements management tool -- for Eclipse that is. Here's a quick run through of the requirements I would have for my requirements management tool:

• Integration with the Eclipse Team API for versioning the requirement documents.
• There are requirement document types:
• General -- which is the catch all and contains an ID field, a title field, a tags field and one big entry field plus a list of attachments.
• Roles and Responsibilities -- A list of possible roles in the project and the task they are required to perform.
• Glossary -- an alphabetical list of business terms used to provide a common language.
• Each requirement is in its own text file and a zip file containing any attachments that the requirement may have.
• Requirements are linked together by levels of refinement. So if I modify a parent of a requirement the other requirements are tagged as needing review.
• Modifications are just tracked by the date/time stamp of the requirements file set.
• The general requirement editor is Wiki based so non-developers can have an easier time hyperlinking requirements to each other.
• Copying and pasting a picture in the editor field should paste a link to the picture. The picture is saved in the attachments zip.
• Holding down Ctrl and hovering a word that is in the glossary will show a hyperlink that links to the glossary entry.
• There is only one Glossary, but each entry is its own file.
• Modifications to glossary entries will trigger a scan (or can be done manually or skipped altogether) on any document that has a word that is written in the modified glossary entry and flag them as needed for review.
• Hovering over a word that is in the glossary shows a tooltip containing the definition.
• History of the requirement is tracked through the Eclipse Team API.
• A way to export the requirement tree to a PDF or HTML or as an Eclipse Help Plugin for external reviewers.
• For performance a local database (may be derby or hsqldb) is used to hold all "index" data that needs to be looked up. Any changes to any of the Requirements documents trigger an update to the database. This is easier than having to create a custom database backend to do this for us. And we can use standard SQL queries to the database and create new ones if needed.
• No access control as that should be handled by the Team API implementation.
• To keep things simple, requirements is a project nature and requirements documents are not usable outside of a requirements project.
• The editor form would have 3 tabs: Edit, Preview, Change History
• Preview should be a rendered HTML containing images and links as necessary. Links will open up other requirement documents in a new editor view.
• The Preview embeds the change history at the bottom as part of the document.
• Cycles are not allowed between requirement documents.
• Saves should be quick, scans may be triggered, but are run in the background using the Eclipse Job API.
• An ID clean up function to help reorganize the documents. Basically set the ID to a defined format e.g. [primary tag] [number] == UCS 1.1
• IDs normally do not get changed though so a warning is shown.
• Open source

Of course this requirements list is going to be vastly different from what JRequisite will be doing anyway, since they are after non textual based information. It would be interesting to see.