Working with Eclipse and Plug-ins

Over the past few days, I’ve been experimenting with the plug-ins and the ODA API. I finally got a nice Javadoc set up of the ODA API, generated from getting the source to the ODA interfaces and getting it into Eclipse and generating the Javadocs from within Eclipse. I’ve put them on the Internet for anyone to see, where they can hopefully stay for a while, accessibly on my Cornell site. I’m quite glad to have made this, as now my complaints from last time no longer really apply. Though I question why this is not made readily available already. But now, on to the Eclipse work…

First, I must say that I first tried following a small tutorial on creating “your first Eclipse plug-in.” As there are not any tutorials that I can find on ODA drivers specifically, I settled for a generic plug-in. I followed a tutorial I found somewhere on the Eclipse website, that was hosted over at EclipseZone. It wasn’t terribly exciting, but it did give me a little button in my Eclipse toolbar that, when clicked said “Hello, World!” Yes, everyone’s favorite phrase makes a comeback. I must admit that I love writing “Hello, World!” programs. One of these days I’ll find out who started this trend. Anyway, on to the Flat File ODA plug-in.

Apparently, the version of the Flat File plug-in that was in CVS on the dev.eclipse.org website is a newer version than the release version. That’s perfectly fine, normally. Unfortunately, this means that it’s completely incompatible with old versions of the ODA framework, such as the one that is currently available to the general public from the Eclipse datatools project website and through the Eclipse download manager.

Luckily for me, I figure out that in plug-in development mode, I can access the plug-ins that are currently usable in Eclipse, and import the source as a project to my workspace. It’s just one tab over, next to the Package Explorer. How convenient!

I’ve been playing with those a good bit since I found that. I made some changes, just to figure out how it all works. First in property and XML files, so that I could change the name from “Flat File Data Source” to “Flat File Duck Source” (first change I could think of):

I’ve made a few other changes as well, such as editing the group on the next page of the New Data Source selector to have 5 instead of 4 rows, and filled the 5th row with another radio button. The previous four were CSV (comma-separated values), SSV (semicolon-separated values), TSV (tab-separated values), and PSV (pipe-separated values). The new one was QSV (quack-separated values). I guess ducks are very important to my code. I didn’t implement the feature, mostly because it would involve a few different source files, but it wouldn’t have been too hard.

On that front, I am currently trying to set up new projects, openmrsdb and openmrsdb.ui, which at first will just be a copy of flatfile and flatfile.ui. Eventually these will be going into the OpenMRS source code in openmrs-contrib, as opposed to a module or the main code, as they plug into Eclipse and BIRT, rather than OpenMRS.

On the front of the Web Service module for OpenMRS, I’ve gone through the instructions on the OpenMRS wiki about Creating your first OpenMRS module. Of course, I’ll be working instead on Burke’s older REST module, so I checked that out as well, and added it as a project that I can directly work on. For that part, I am completely set up, as far as my developing environment goes. I will get some general practice with web services soon, so that work on the REST module can get started.

The next order of business is getting at least a shell of the ODA modules set up. But then again, that may wait a little bit, as today I got Integrating and Extending BIRT by Weathersby et al. in the mail. I would like to note here that the USPS is an odd service. I saw the mail truck drive by today, and went to check the status of my package, which wasn’t supposed to arrive until June 15th (10 days early!). As I noted that the tracking said it was still in Jersey City, NJ, USA, there was a knock on the front door, which was the mailman with my package. I can understand the fastness, but I would really like some better tracking. I live in New York, which is at least a day away from Jersey City by mail, if it was going fast. In any case, I’m glad to have the book, so that I can have a reference other than the API and the Flat File implementation.