Target Definition to the Rescue!

Congratulations to the PDE team for saving my day!

I just switched my day-job development from Windows to Linux.  I use IBM Rational® Software Modeler™ every day for its various advanced features, and among other things the software that I develop extends some of its features.  Therefore, I self-host my PDE.

As it happens, my software project also depends on other Eclipse-based components that are not included in RSM.  So, I install them into my RSM workbench.  On Windows, this works fine because I am an administrator of the system and p2 installs the stuff into the shared bundle pool.

However, on Linux, the picture turns out to be a very different one.  I installed RSM as root but I run it as a regular user.  It seems that some kind of funky extension to Equinox causes p2 to install my extra features into my home directory, and the launcher finds its configuration there instead of in the main product installation location.  Very cool!  Great for a multi-user environment.

However, not so great for my PDE target.  PDE only recognizes the plug-in locations installed in the product, not this extra location in my home directory.  Enter the PDE Target Definition.

drum roll ...

I use the New Target Definition wizard to create a new PDE target, and it creates one that includes my current Eclipse configuration by default.  Then, I add another location in which it will find plug-ins.  I could even, if I wanted to, add plug-ins from my workspace, although this seems odd because the workspace generally is implicitly in the target, anyhow.

PDE Target Definition Editor

With one click in the top right corner of the editor, this target is installed in my PDE environment and it now finds every plug-in that I need.  It's too easy!

PDE Target Preference Page

Who Knew? Comparing Directories in Eclipse

Well, isn't that a pleasant surprise to follow a rather unpleasant one.

After having spent much of the day working on OSGi-bundle-izing Apache Batik 1.7 in the Eclipse Orbit project, I discovered that the re-distribution of the W3C CSS SAC 1.3 API that is included in Batik 1.7 is, in fact, the real original content as provided by W3C.

"Great!"  you might say.

No.  The reason I know this is that what I actually discovered is that the re-distribution of the SAC 1.3 library in Batik 1.6 was a modification of the original W3C code, that I had bundled in Orbit way back when.  Mostly, the changes are either just in the CVS ID in the header comment (Apache and W3C both checked the sources into CVS) or fixing typos in the doc comments.

My heart sank when I saw that one class, the CSSException, actually had functional changes.  A bunch of its code was removed by the Batik team.  Ugh.  So, now the Orbit bundle that for so long has been touted as "the" W3C CSS SAC 1.3 API in fact isn't, and I have to figure out what kind of version number to apply now to make the new bundle look like the real deal over the old one.  The org.w3c.css.sac_1.3.0.v200803081811.jar bundle is not authentic.

Anyhow, the real point of this blog is not to complain but to congratulate the Eclipse Team Team (tee hee).  I had always used BeyondCompare to diff directory structures, but I don't have it on my current system and I was impatient, so on a lark I thought "Hey, let's see if I can do Compare With -> Each Other..." on directories in Eclipse.  Well, of course I can!  That's how I found my little Batik/SAC conundrum:

I should know by now just to assume that Eclipse can do these things.  Silly me.

Good work, Team people!  This is one more task that I don't need to escape my cozy workbench for.

OCL: Who Cares?

This week, the OCL 2.1 RTF has had to re-launch the voting on its first ballot, because it failed to reach a quorum.  With a 10-member voting list, 2 votes just didn't cut it.  And these were the two companies that put some effort into resurrecting this specification by addressing a substantial number of issues.

It's disappointing to see that there is so little interest from the OMG membership in the health of this specification that should, and I think was intended to be, a cornerstone of the the MOF architecture.  There is still interest in the user community, judging by the continued influx of issue reports.

No metamodel is complete without constraints that specify the well-formedness of instance models.  And OCL could be a key tool in that department, if it can keep up with the evolution of MOF and UML.  Indeed, it already seems to be an important part of several Eclipse modeling technologies, as I hope to demonstrate at EclipseCon 2009.  However, the current state of the specification makes the implementation of conformant tools difficult and interchange of OCL models impossible, because the language is imprecisely and inconsistently specified (some bits aren't really specified at all).

A few of us are working hard to reinvigorate and reform this specification, but we need help.  With just two OMG members involved at this point, it is difficult even to get through a vote, and I worry about how relevant the product will be that results from such a small collaboration.  So, pitch in with your time (it doesn't take much) and elbow-grease to make OCL succeed!  Let's not let this thing go the way of the dodo.