Alex headshot

AlBlue’s Blog

Macs, Modularity and More

EclipseCon: NASA, scripting, Mac OS X and Apache OSGi bundles

Eclipsecon Conference 2006 Eclipse

Man, Tuesday was busy. I arrived at the conference at 08:30, and didn't get back until 23:00. So, what happened? There's been enough comments about Joel on software (Tuesday's keynote) that I don't have anything extra to add other than I agree with everything that was said about it - it was hilarious. There was also a presentation on NASA's use of Eclipse RCP to provide telemetry data to the Mars rovers; Ed's already blogged about it.

There's been a lot of interest in scripting in Eclipse; though it's clear that there's several different types of use of scripting:

  • Using a scripting language to contribute simple hooks (actions, view sorters/filters etc.)
  • Being able to script the user interface for demonstration/testing/tutorial purposes (possibly linked in with a cheatsheet)
  • Being able to write platform-manipulating code in another language (e.g. manipulation of JDT's structures to do refactorings from python)

Most of the scripting support seems dependent on having an in-JVM language; so Jython and Eclipse Shell are possible candidates, as well as Rhino (JavaScript) (which is used in the Eclipse Monkey scripting). Unfortunately, it means that PHP support is likely to be some way off since there's no JVM engine for processing PHP. I was fortunate to have lunch with Ward Cunningham after the scripting session, and hopefully we're going to get together in a scripting BoF to see if we can do some hacking in EclipseMonkey.

I also got the opportunity to meet Mark Lewis, from Microsoft Research, over lunch. He's a fascinating guy. He spends his time liasing between research universities around the globe, but with a particular interest in developing universities rather than the well known ones in the West. One of the problems he faced is one of network connectivitiy; some of these research institutes really are in the middle of nowhere, and internet connectivity is not always available, or fails intermittently. So downloading large codebases just doesn't work for them. The upshot is that a bunch of stuff gets mailed out on DVD periodically; whilst it might seem like a lower bandwith solution, it actually works really well since they effectively have local (read-only) caches of the information they need. So if you're working on a system that requires large amounts of data (such as the update manager :-) then you need to make sure that it's restartable from the last place you got to, even if that's in the middle of a file. Starting by downloading the new file again just doesn't work for some places. Another advert for Commons-Net?

Speaking of which, I managed to bump into someone from Apache at the exhibition hall, and asked why the commons Apache Jars aren't OSGi enabled (by having the appropriate manifest entries etc.) It seems that there's a interest in this happening both from inside and out, but that there's not necessarily the experience on the individual teams to make it happen. Hopefully I'll be able to provide assistance towards that effort, so watch this space. (By the way, does anyone know if there's a firm requirement for the name of the Jar to be the same as the symbolic name of the bundle? I've not seen it documented firmly, but I can imagine that it may cause problems.) After speaking to Greg at this morning's Apache keynote, the goal seems to be that if we can get Maven to generate OSGi meta-information in the build, it will be much easier to encourage widespread adoption of OSGi bundles as a way to go. There's also Felix, which is an Apache OSGi R4 server that as it nears completion will hopefully encourage adoption of OSGi bundles as a default coding practice.

I also managed to talk to Martin about jLibrary before his voice started giving up. It's really very cool indeed; it allows you to manage content and provides a search and categorisation engine for documents, as well as a built-in viewer and for Word documents, can even open up the document via OLE. It uses Jackrabbit to store the information, and as such, has both version control and the ability to mount via a WebDAV share. Because all of this is handled automatically, you can provide access to a document repository just as a network share, and when the document is saved, it's updated. Plus, any document meta info (author, date of change) is imported from both (x)HTML and MS documents. If you're at EclipseCon, look up Martin's stand (it's at the back left) or download jLibrary and give it a spin.

There were a couple of interesting BoF sessions last night. The first I attended was a discussion on the Rich Server Platform led by Wolfgang Gehner (of Infonoia). This uncovered two independent subgroups; people wanting to use Eclipse/OSGi runtime on the server to create componentised servers, and those wishing to create componentised user interfaces for web applications generated by a server. There was lots of good discussions, and Wolfgang's working on a proposal for Eclipse in the next few months. Perhaps there will be some change in terminology to distinguish a plain server-side Equinox-style use from one that's generating rich internet applications on the server side.

The second was a state of play on Mac OS X. This was attended by Veronica and Steve from the SWT team (as well as another that I didn't recognise, sorry) and also a couple of memberes from the Apple Java engineering team. Good to see the two talking together. Unfortunately, it doesn't look like the SWT_AWT bridge is going to be fixed soon (and certainly not for 3.2) but there's pomising possibilities and it may be done in time for the next version of Eclipse. Those with MacBook Pros said that Eclipse screamed on those systems (3.2M5+) but it doesn't look like SWT/Intel is being backported for 3.1; though since it's just a compile issue, it should be possible to add that functionality individually. There was also minor griping about how Eclipse isn't structured like a proper Mac application both in terms of file layout and in terms of the fact it launches a second process. Unfortunately, that's outside of the SWT's remit and although completely useless in an RCP, the second process allows the IDE to relaunched (just one more facet that shows Eclipse hasn't broken free of its IDE heritage just yet). I've got a repackaged version of Maclipse which I'll be making available at Sourceforge via in the near future; but I've not subjected it to enough testing and with enough variations to release it just yet. For some reason, I'm otherwise occupied this week ...