An Auto-configuration Plug-in for Eclipse

Have you ever written a plug-in and thought it would be neat if you could automatically
detect the programs the plug-in needs, so you can make life a bit easier for your users?
If so, the auto-configuration plug-in for Eclipse, Discovery, is just what you need.

Once you've installed the plug-in, you simply extend two extension points to get the
functionality you need. The first extension is for finders; you specify a class that finds the
program that you want discovered for your users. The other extension is for consumers; in
this extension, you specify a class that inserts the services (the term we use for programs,
or any other thing found by the finder) into your plug-in. And that's pretty much it. You can
check out our wiki site to read the documentation and download a few source examples.

Note that Discovery is built on top of ECF and so if you're used ECF's API, you will have
no trouble working with Discovery.

The beginning of the end

Oh man, the Summer of Code will be ending on Friday. I've spent all of today writing a user manual for my Auto-discovery project. I'll also write an article and try to get that published as widely as possible; nothing like publicity to get your code into the hands of users, I say. I didn't expect the Summer to end so soon...

In other news, I spent most of last week creating a Web site. In the process, I read the CSS 1.0 specification from beginning to end. Compared to the CSS 2.0 spec, CSS 1.0 is simple, small, and darn elegant. Of course, things like absolute positioning become a bit of a pain, but you really wonder if they couldn't have made CSS more powerful without adding so much more stuff to it.

JREFinder/Injector works, period

I just committed the code that completes (functionally, at least) my JREFinder/Injector pair. The JREFinder checks a number of locations and installs any JREs it finds there. I recently added a polling mechanism to the underlying Discovery plug-in that makes it poll all such "found" JREs and notifies its clients when these JREs no longer exist. JREInjector is one such client, and when it gets the "unfind" event, it uninstalls the JRE that was unfound. Thus, when I run my Eclipse app, I can install multiple JREs and they're automatically add to the JRE Preferences list. Then, I can go and delete or rename the JREs and they're taken off the list...automatically!

For everyone who contributed the locations of their JRE installs, Thank you very very much.

JREFinder works (almost)

So, at the end of last week, I'd gotten my JRE Injector (the plug-in that injects JREs found by the Finder into Eclipse's preferences page) working. However, when I open the Preferences page and check the list of installed JREs, I only see the last JRE injected. All the others don't show up! Very strange. The good thing is that this week, I'll be putting JREFinder/JREInjector on the back-burner and beginning work on a new project to provide discovery services for. What'll it be? C/C++ Development Tooling? PHPEclipse? I'll let you know once my esteemed mentors give the word.

This past weekend, I participated in the ICFP programming contest. It was *hard* and I only finished writing the first part of the interpreter (DNA->RNA) on Sunday night. I'd used Java and abandoned it, then moved onto PLT Scheme (shooting my productivity up). However, I got screwed by type errors and not being able to debug programs in as fine-grained a manner as in, say, GDB.

So now I'd like to know, are there any statically typed programming languages out there (preferably functional) that have a good IDE (auto-completion is nice), a debugger that allows you to examine variables anywhere along the execution path, and a graphical testing framework (kinda like Eclipse's JUnit)?

P.S. my team name was Ogachyuallincheck and as you'll notice, I wasn't last :-)

Call for entries...

So, as part of creating an auto-configuration framework for Eclipse, I'm writing an example plugin that tries to find the installed Java Runtime Environments on a system. It'll be done heuristically and not with an exhaustive search and so I need your help. Please tell me, in the comments pages, the path to where you have installed the JREs on your system (Linux, Windows, Mac, whatever) so I can compare and extract heuristics from them. If you're running Eclipse, you can find the locations by going to Window > Preferences... > Java > Installed JREs. Mine, by the way, are at C:\Program Files\Java\j2re1.4.2_15 and C:\Documents and Settings\onnadi3\Desktop\eclipse3.3\weme-win-x86-ppro10_6.1.1.20061110-161633. Thanks, folks.

By the way, last week, 5 years since I started taking piano lessons, I finally played the last song in my Essential Keyboard Repertoire. I can finally claim the title of intermediate level-pianist. *sniff* Ms. Rivadeneira would be so proud...

Inserting JVMs into Eclipse

As one of the use cases for my Summer of Code project, an auto-configuration plugin for eclipse, I've been trying to automatically detect installed Java Runtime Engines (JREs) on a system and load them into Eclipse's list of installed JREs. It ain't easy, lemme tell ya.

I first tried to insert the JRE's data directly via the Preferences API. That didn't work because format in which they're stored in the Prefs is not API, hence there are quite a few values that have to be set *very* carefully.

I next tried to dynamically load an extension for adding JREs to the list using IExtensionRegistry.addContribution but that method wouldn't let me add persistent entries. I got an idea from Phillipe to create a plugin with an extension point which I would load from disk as needed and wala! have dynamically added JRE entries. Eventually the idea was scrapped, because there was a seemingly easier way to do it using the VMStandin class.

I tried using it for a while, even resorting to using internal APIs but I kept getting weird exceptions. Then I cam in to work this morning and after updating, I noticed that Markus had kindly gotten the VMStandin class to properly insert JREs into Eclipse's list. This was one chunk of code that I was very grateful to see. Here it is for your enjoyment:

// Take the first VM install type that claims the location as a
// valid VM install.  VM install types should be smart enough to not
// claim another type's VM
for (int j = 0; j < vmTypes.length; j++) {
 IVMInstallType type = vmTypes[j];
 IStatus status = type.validateInstallLocation(location);
 if (status.isOK()) {
  VMStandin standin = new VMStandin(type, type.getId());
  standin.setName(location.getName());
  standin.setInstallLocation(location);
  standin.convertToRealVM();
  break;
 }
}

In other news, H.P. Lovecraft has just reintroduced me to the joys of reading horror. I just read The Tomb and was blown away by the imaginativeness of the stories and the flowing flowery language. And I also discovered that he is the source of famous names as Sephirtoh, Chthon, Alhazred, and Arkham.

Status update

This is my a status update for today's Eclipse SoC meeting. You can join us on Thursdays at noon (EDT) in #eclipse-soc.

My goals for this week were:

1. Make JREFinder check in a few places for JREs
2. Package it as a feature
3. Add to SoC CVS
4. Write the "jdt preference injector" which injects discovered values into the corresponding jdt preferences.

#1 Make JREFinder check in a few places for JREs: I wrote an example JRE finder that searches in Program Files for installed JREs; works only on Windows.

#2 Package it as a feature: I found out how to do so here http://wiki.eclipse.org/index.php/FAQ_How_do_I_create_a_feature%3F . I shall package my project as a feature once the other three items are done.

#3 Add to SoC CVS: Done. Our code is now available at soc.eclipse.org:/cvsroot/soc/org.eclipse.soc.discovery. Thanks, Markus :-)

#4 Write the "jdt preference injector" which injects discovered values into the corresponding jdt preferences: I'm still working on this. The classes that allow me to inject values into JDTs list of VMs are in an internal package and so I can't use them. I have sent an email to the jdt-core-deve mailing list asking for help with this problem.