Saturday, 19 January 2008

EMF and eRCP: Two Great Things That Go Great Together

The Eclipse Modeling Project and eRCP are both Jolt finalists. Gorkem blogged about it already. He also blogged about the last MIDP specification ever and about the latest eRCP release. So this, along with Ralph's request for some background information on the modeling project's relevance to the embedded community got me thinking about how beautiful the Isle of Saints will be in February.

Just kidding, it got me thinking about how EMF is a lot like chocolate: it's goes well with so many things and is kind of addictive once you get started. So in true manic developer style, I left all the other half completed important things on the back burner, and decided to dive into eEMF, an eRCP-enabled version of EMF, much like the RAP enabled version that's partially done. Or maybe it's completely done; I still have to test it now that RĂ¼diger Herrmann helped me figure out how to launch the darned thing. It's the little things that cause me the biggest problems...

First I tried to extract all the eRCP source code from CVS. I have this compulsive need for being able to butcher other people's code. There's kind of a hodge podge in that DSDP repository, but it didn't take me long to guess that I wanted all the stuff under org.eclipse.ercp. So I extracted it but the result was kind of a build disaster. I have no idea how this stuff is supposed to be set up and built. Projects would be a lot more open and would get better patches if it was easier for folks to set up the project's source code. For EMF we have a detailed wiki document for this, including the instructions for the elaborate contortions we must go through to work around 109137 so that we can bootstrap our development environment. That's right, we eat our own dog food in the modeling project, so we ensure that's it's fine cuisine that's far too good for dogs.

So I gave up on on the CVS extraction and decided to grab the shiny new 1.1.1 download and use that instead. Unfortunately that immediately left me thinking, hey dudes, where the heck is the SDK? It's open source and I want the darned source because even if I can't butcher the code I really do want to see it! Oh well, enough griping. Things really improved after this. Fortunately I already had a CDC 1.1 JRE set up, using the handy dandy wiki for that, from a previous attempt to convince myself that EMF 2.2 really does work with Foundation 1.1, which I always thought was extremely cool given that it wasn't even a goal.

In less than three hours I was able to get a functional application working! Most of the changes were to delete the code that depends on the optional org.eclipse.core.resources plugin. I had to delete large swaths of org.eclipse.emf.edit.ui, since lots of things in eRCP's UI apparently aren't supported. After making the compiler happy, I made sure that the org.eclipse.emf.ecore.xmi plugin was still working when using the microXML implementation in eRCP; indeed it worked like charm. Finally I needed to build a little GUI application, so I snarfed eERPC's eWorkbench example and turned it into a com.example.library.ercp.eworkbench example. It displays a little tree view of the Library model as well as a copy of the Ecore model of itself.

I'm very impressed. This eRCP stuff was really easy to set up and use. I put all the results in 215378. I suppose this means we really ought to produce a build for EMF 2.2.1000. Won't Nick be pleased! I'll wait to get some feedback to see how much interest there is in this.

I even tried to get the XSD model working, but the ability to serialize a DOM seems to be absent and the level of DOM that's provided doesn't support events. So I disabled these aspects to enable a read-only version of XSD, which would still be useful to support EMF's ability to read an XML instance with a schema location for which the XML Schema to Ecore mapping is used dynamically. So I tried to get that working, but to my horror I ran into what looks like that darned Crimson DOM problem from the old Sun JDK that just never got fixed. This time I could provide a patch and we have the code in our Eclipse CVS so I'm much more hopeful to get it fixed.

So ends another compulsive day. Thank goodness that vacation is looming on the horizon...

No comments: