I have been working on an Eclipse Plugin to support people who use my rules engine and workflow engine.

These both require you to specify stuff in a text file, rules in one case and process definitions in another. There is syntax to get right and the plugin provides a helpful editor that tells you about syntax errors, suggests things you might need to enter, colours keywords etc. It isn’t nearly as smart as the Java editor in Eclipse but it should help.

Some people might be surprised I’ve done it this way rather than a pointy-clicky user interface that non-programmers can use to define their workflows and rules. But I have been around this stuff a while now and I have yet to see a non-programmer actually write any rules or any workflow. Instead I have seen pointy-clicky user interfaces that are too dumb to actually do the job because some things are just too hard to make that easy.

Also, even if non-programmers did get directly involved, they would have to learn how to handle issues like version control and rollout which would mean they would turn into… programmers.

So our products accept reality and make it as easy as possible for programmers, especially Java programmers, to work with them. Hence the need for an Eclipse plugin that helps with the editing. I use Eclipse all the time, have done for years, partly because of the way people extend it with plugins. There are alternatives to Eclipse but one plugin is enough for now.

Actually writing the plugin is pretty simple. It took less than a week to throw it together. The writing and testing part just needs one Eclipse plugin project and you write the code and tell it to run. That launches a second copy of Eclipse with the plugin installed and you try it out, step through with the debugger etc. Easy stuff.

Deploying it however, that was much more complicated.

The way the people who designed the plugin architecture would have me do it is to create several different projects which are interrelated. I need one for the plugin, of course, another for the ‘feature’ which contains the plugin, another for the ‘update site’ which builds the repository other people can use to download from. If I use Tycho, which is what I’m supposed to do if I want to build with Maven, then I need another couple of projects as well. That seems too complicated, at least for a single plugin project. If I had several plugins I wanted to roll into one site then maybe, there would never be more than 3 ‘overhead projects’ but…not this time.

Instead I cooked up an Ant script which builds everything in one project. That should make it very simple for anyone who wants to pull my source code from Github and try building it. One complication is that the build.xml file (which is what Ant looks for by default) kept getting deleted by the Eclipse wizards so I changed its name to build1.xml. The file is a bit messy still but it does run okay and it delivers an update site in the ‘site’ subdirectory.

That means I can commit the site directory and use the Github project as its own public update site. So people who don’t care about the source code and just want to install the plugin binaries into their copy of Eclipse can point to there and get it. It took me ages to work that out. I was expecting to deploy it into Sonatype, which is where I deploy all my other binaries, but they are Maven binaries and Eclipse update sites have a different structure. Fair enough, but there were hints around that it was possible which made me keep looking too long. Anyway, this approach is easy and seems to work fine.

Edit: I have since moved the update site to http://www.madurasoftware.com/madura-eclipse/