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.

Midway

Oh happy day it is, when my SoC project reaches its halfway point. The aim of the project was to allow Eclipse plugins to automatically find all the resources they needed on a computer. Well, I have finished implementing the component that routes resources to the plugins that need them.

In other words, I finished implementing org.eclipse.ecf.discovery.IDiscoveryContainerAdapter. However, it was just today when I wrote an example service finder and service consumer and they both communicated to each other via the container adapter that I realized that I'd hit a milestone.

What is left now is to actually devise a JRE finder that will locate all JREs installed on a system (for example) and communicate that to another plugin that needs the information. With a solid example like that, we can then start writing manuals and articles on using our Discovery plugin, and evangelizing to the ends of the Eclipse community.

By the way, visited the Lava Lounge yesterday. It had 3 separate dance floors with their own DJs on each of its three floors. Wow! I must say, there is something to living in the big city.

Where are you, Amanda Bayliss?

I've spent the past two days trying to implement the central component for Discovery. Even though I'd done it before, reimplementing it in the new style my mentors told me is proving tedious.

Well y'see, the org.eclipse.ecf.discovery interfaces are part of the larger ECF that is, while beautiful, a tad complex. I'm mostly done with IDiscoveryContainerAdapter (which keeps track of services as they come and go and notifiies consumers about these services) and it kinna hurt. For instance, to implement registerService(IServiceInfo serviceInfo), I had to implement IServiceInfo. The IServiceInfo constructor needs to take an IServiceID, and IServiceID needs 4 methods to be implemented. And it goes on, for almost each method, I'd need to create some class that implemented some interface, and then I'd need to write tests for the class I'd just created *and* for the IDiscoveryContainerAdapter I was originally working on. Its been slow, but now I've got only two methods to go...

I just finished reading The Yiddish Policemen's Union: A Novel, a novel about the Jewish state of Sitka (in Alaska, not Israel) and a Yiddish policeman whose life seems to be crumbling around him. Its very Jewish, very funny, and it had me howling in sorrow when the book finally ended.

Rearchitecturings

I had a chat with Scott Lewis on the #eclipse-soc channel at irc.freenode.net. He's one of the developers for ECF Discovery. ECF Discovery aims to (I hope I get this right) provide a high-level API for remote i.e. network based, services to keep aware of each other. Hmm, sounds a lot like the Discovery project I'm working on. My mentors sicced me on ecf.discovery to figure out if we could reuse any of their components, and after talking with Scott Lewis, it seems like we can use a lot of their code. Looks like a fair bit of my code will be going out the window soon...

In other news, I read The Little MLer yesterday and it provided a very easy-to-understand introduction to ML, a programming language family I've been trying to learn for a while now. I still don't fully understand signatures and functors, ML's version of Java interfaces and classes. If I do, ML might just supplant Scheme as my favorite class of languages.

Synchronize

Spent yesterday trying to configure my plug-in so my mentors would be able to run it on their machines. Who would have thought it'd be so hard to get the same program to run exactly the same way on multiple machines when using a "cross platform" language like Java?

Anyway, I'm also reading "Eclipse: building commercial quality plug-ins." I'm just on the third chapter and I've already learnt quite a lot. Most importantly, I found out that Eclipse has a Find in Files feature. I'd always gone round telling people that NetBeans is better than Eclipse because it had Find in Files and Eclipse didn't. Well whaddaya know: Ctrl+H and clicking on the Java tab does just the trick. Granted, its nearly impossible to find but still, its there!

It works

Today I finished the SimpleConsumer plug-in that bugged me last week and so, there now exists a full suite of plug-ins that shows how Discovery is meant to work. Simply download the sources (you'll probably want to use the J9 6.0 JRE. We're using it for compatibility with Provisioning), and start the Discovery, SimpleFinder, and SimpleConsumer bundles as OSGi services (and probably in that order, too :-) ). On the console, you should see a message saying that a certain string has been found. Wala! It works.

Of course, its not very interesting right now but its what's behind the scenes that's really groovy. Discovery, when started, waits until Finder services are started and then it makes a note of them and what programs they can find. Then, when a Consumer is registered, it requests a ServiceDiscovery service that was started by the Discovery bundle; the ServiceDiscovery then allows the Consumer to query for programs that have been found. A tad over-engineered? Sure sounds like it, but this architecture allows all Finders and Consumers and Discovery itself to come and go as they please while the system as a whole keeps working. As usual, thanks to Markus and Remy for pointing me in the right direction at our weekend meeting.

In other news, I went to Halo again on Saturday and, miracle of miracles, four ladies started dancing with me unbidden. Yes, F-O-U-R. At once. That made for another interesting night, and pushed Halo up in my ranking of best places to hang out.

Can you guess what I'll be doing tonight...you guessed right!

Hi Dad, Hi Mom

Past two days: frustrating. I took on two tasks and have failed at them both.

1. I wrote a simple UI plugin that would query Discovery for the services sent to it by the various finders. However, I could not figure out a way to query the Discovery plugin from the UI plugin. Hmm, I thought. I ran to Barnes & Noble, read the book on Eclipse programming, thought I had the answer, came back and tried it. It didn't work.

2. I'd written a MultiMap class (a hash table from keys to multiple values) and then tried to write tests for it. Here's the code

public class MultiMap extends HashMap {

/* If KEY exists, insert VALUE under its Set,
* otherwise insert VALUE into a new Set.
*/
public Object put(Object key, Object value) {
Object oldValue = this.get(key);

if (oldValue != null){
oldValue = ((HashSet)oldValue).clone();
((HashSet)(this.get(key))).add(value);
}else {
super.put(key, new HashSet().add(value));
}

return oldValue;
}

and here's the exception

java.lang.ClassCastException: java.lang.Boolean


For some reason, get(key) was returning Booleans instead of HashSets! Why? And no, I was not inserting Booleans of any sort into the MultiMap.

Oh well, here's hoping I get some inspiration by tomorrow...

P.S. Hi Dad. Hi Mom. Like my blog?

Refactorings

There's not much to say today. I refactored the source code, added comments, and then sent it over to my mentors for their advice. Hopefully they'll have lots of comments and I can be productive tomorrow. Otherwise, I might find myself playing Quake 3 Arena all of tomorrow...ahem...as I spent much of today doing.

Also, last night I read Kill the Messenger in Reader's Digest condensed book form. It was a snappy, if slightly simplistic, murder mystery. What I really loved was the author's visual imagery, as when a female detective who seemed to the reader to be much more interested in fashion that police work showed up to a murder scene in the middle of the night in head-to-toe skin-tight leather. Very entertaining.

Step 1 again

Yes, I know...I was a bad boy for not blogging (or doing much work either) yesterday, but I came back with a bang. Since my task for this week was to do what I'd done previously, but using OSGi services instead of extension points, I followed these excellent articles to figure out how to get my task done. The end result: I now have the basic infrastructure for adding and removing service finders. The next step will be to define a convenience library for finding things on a filesystem, and defining extension points so that service consumers can find the discovered services (yeah, still have to do EPs). Here are the latest sources for your browsing pleasure.

By the way, over the weekend I read Sam Harris' The End of Faith: a book that partly tells how religious moderates are endangering the world by tolerating fanatics. I also finished Applied Cryptography, a programmer's introduction to the subject that manages to insert humor into the myriad stories of Alice and Bob and Eve; it was a strangely satisfying read.

P.S. I was motivated to work long and hard today, thanks to a long and interesting night last night at Halo that broke the monotony of a week spent reading and coding. However, I have to ask, Why are so many Atlantans partying on a Monday night?

Lethargy

Didn't get much done by way of productive work. However, I read the Eclipse coding standards and a couple other documents and I think I've got a good handle on what yesterday's discussion was all about.

Part of the reason I've been so unproductive is that I had (my first ever) $10 cocktail at Trois bar. From the way I felt this morning, it was certainly worth it.

Swamped

So I couldn't figure out how to write the extension points that I was stuck on yesterday so I cried to my mentor, Markus, for help and he told me to go to the #eclipse-soc channel to discuss. About an hour later, we'd decided on a name change for the project (from eclipse-autoconf to org.eclipse.discovery), made a few architectural changes (like not using extension points. I'm still not sure about that), decided on a few constraints (using Java 1.3 instead of Java 5), and I was given 5 documents to read before making any further changes to my code. I am going to have Eclipse dripping out my ears by the end of this Summer, no doubt (but I'm still excited, I won't lie). You can read the meeting logs here. The guys in #eclipse-soc are hilarious.

First Payday

Yup. 500 smackeroos in the form of U.S. dollars were handed to me yesterday by Google, Inc. via Western Union Money Transfer. I was pleased in the process.

Today, at the suggestion of Markus Kuppe (my other Summer of Code mentor), I tried to create extension points in my auto-configuration plugin so that other plugins could attach their "resource-finders" to mine. Hmm, this might need some explanation... Y'see, Eclipse has these things called extension points which are kinna like sockets where you can plug in extensions. My plugin (Eclipse autoconf) will eventually plug into Eclipse and provide an engine that executes resource discovery rules (here's a link to my proposal again just so you know what's going on). Other plugin writers, instead of rewriting service discovery routines, will simply be able to write some kind of simplified script that says things like "check here and here and here for so and so service". Now they can plug their plugin (technically, they'll write *another* plugin for this) into the extension points in mine, my autoconf plugin at the right time will execute their rules, and voila! the end user sees a list of all the binaries, ports etc. that he would have had to fill out otherwise automagically filled out. So, that's why today I worked on adding extension points today. I don't understand how to define XML Schema and this is apparently required to define extension points, so I'll try and figure it all out tomorrow.

First commit

Today I made my first commit to Eclipse. Well, not to the Eclipse code base itself but to the Eclipse incubator project at SourceForge. Version 0.0.0.0.1 of Eclipse-autoconf is now available to the world at http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/eclipse-autoconf/. All it does for now is pop-up a box that tells you whether you have a JRE installed at one location (the location where the JRE is installed on my computer). Of course the goal is to expand this so it discovers JREs in different places, publishes these locations to some format that the the Java plugins can use, expand the discovery services to other programs apart from the JRE etc. Yup, there's lots of work to be done but I've taken the first step on my thousand mile journey. Hellz Yeah.

By the way, I've been reading quite voraciously lately so I'll be posting each of my conquests as they fall. Last night, I read Simon Singh's "The Code Book". It's a fascinating account of code making and breaking throughout history, and its only whetting my appetite even more for the ICFP this year.

Aloha, World.

My name is Oge (or onnadi3 on the irc.freenode.net/#eclipse-soc) and I am participating in Google Summer of Code 2007, in partnership with the Eclipse foundation. My project aims to to design an Eclipse plugin that allows the binaries required by other Eclipse plugins to be automatically located. So, for example, let's say you installed the C++ plugin, my plugin would automatically tell that plugin where to find GCC or Visual C++ or whatever compiler you use so that YOU don't have to. Pretty sweet, eh? I thought so.

Well, I started work today. My goals were to get a "Hello, World" plugin running, put that code up on SourceForge, and then perhaps write some heuristics for finding the Java Runtime Environment on a system. I knocked out part 1 in 10 minutes (heheh), but then figuring out how to create modules in the CVS repository in SourceForge took about an hour and so I ran to one of my mentors, Herr Remy Suen, for help and moved on to part 3. Yeah...it ain't done either but I know how to do it and I'll be on its ass tomorrow. My work day is over now--ends at noon everyday--so I'll soon head out to play the piano and then start practicing for ICFP 2007.