on Nov 19th, 2008More changes afoot…

It was almost exactly 10 months ago that I blogged about leaving IBM. A lot has happened since. Perhaps the coolest work-related thing is the announcement that came out this morning here at the Eclipse Summit Europe. Today we announced that Code 9 and Innoopract have created EclipseSource. The idea of EclipseSource is to really get behind the Eclipse runtime vision and push Equinox, RAP, RCP, e4, ECF, … to new levels of consumability — both at the technical level and the pragmatic business level.

Jochen Krause (Innoopract CEO) and I will lead this new team. We share the vision of a commercially backed, highly modular runtime platform. Technology for which businesses know they can get support, technology enhancements and extensions, and industrial-strength management infrastructure. That technology is Equinox, the runtime elements of Eclipse, in concert with product offerings that will be announced in the near future.

on Nov 18th, 2008ESE Hackathon

This post is a little late but ESE is just starting and I wanted to highlight the Equinox Hackathon that is going on at the conference. This event is designed to encourage people to start building bundles, experimenting with Equinox and looking at services.  It’s a great chance to experiment and try things out.  Feel free to participate whether you are at the conference or not.  There will be a presentation at then end of the conference to highlight some of the things that were put together.

on Oct 28th, 2008Tip: PDE Build and Binary Cycles

I recently spent some time with a client removing some cycles in bundles and discussing why cycles are evil in the first place. The problem is that even if you remove cycles from your own code, the code you depend on may not be cycle-free. This could be for many reasons, most of the time it’s due to legacy. So after some bundle cleansing, we setup an automated build… and had this dreaded error message come up in the logs:

“A cycle was detected when generating the classpath…”

I was sure this time that the fault didn’t lie with my client’s code, but someone else. I was right… the messy world of third-party dependencies can bring in some interesting baggage. This error was caused by a few third-party libraries that participated in a cycle, which is OK during runtime, even though poor architecture in my opinion. So how do you get around this? In the past, it was difficult in the Eclipse-world, but since 3.4, PDE Build was enhanced to allow binary cycles (cycles in the target you’re building against). To enable support for this, you simply have to specify the ‘allowBinaryCycles=true‘ in your top level build configuration properties, similar to where you specify properties like baseLocation. As of 3.5M3, PDE UI will automatically enable binary cycles support and this option can be toggled via the UI:

Hope this helps! Happy building and avoid cycles when you can!

on Oct 28th, 2008Code 9 does Dallas/Fort-Worth

The next stop on the Code 9 travel train is the Dallas Fort-Worth area this week!

Jeff and I will be at a conference and doing some client work so if anyone is interested in having dinner or frosty beverages, let us know. We also have some cool demos we’re planning to do for Eclipse Summit Europe if you want a sneak peak or can’t go to ESE.

By the way, this month at Code 9, our frosty beverage of choice is a seasonal variety, Dogfish Head Punkin Ale.

Anyone else have a good seasonal brew that they have been drinking lately?

on Oct 20th, 2008Code 9 at Eclipse Summit Europe

One of my favorite Eclipse conferences is coming up, Eclipse Summit Europe 2008! Multiple people from Code 9 will be speaking at the event, here’s a snapshot of our activities:

I hope people will be able to attend because there is going to be a lot of exciting work going around the e4 and RT projects. There’s also going to be an Equinox hack-a-thon! I hope to see everyone there!

Also, as a reminder, the conference hotel is holding rooms until tomorrow, so please book your room soon!

on Oct 16th, 2008Ian Bull joins Code 9

Ian Bull, the component lead for Zest, the Eclipse visualization framework, has joined Code 9. A lot of you may know Ian from his work on the plug-in dependency visualizer:

It was a pleasure to mentor Ian on the plug-in visualization project as I got to witness his enthusiasm first hand. Ian recently completed his PhD at the beautiful University of Victoria, has a second child on the way and brings forth a lot of good experience and energy. Expect to see great things coming from Ian in the future.

on Oct 9th, 2008PDE Leadership Changes

I am really excited to announce that Chris Aniszczyk and Darin Wright are now the official co-leads of the PDE project.  Indeed they have been fulfilling this role for quite some time now so it is great to have their contributions recognized and formalized in this way.  Please join me in congratulating Chris and Darin and wishing them all the best in the challenges that lay ahead.

Why the change?  For many years now Wassim and I have been the official leaders of the PDE project. Wassim is one of the early guys on the UI side of things and has contributed tremendously to the RCP tooling and many other facets of PDE. For my part I’ve been involved with PDE from the early days, mostly on the build side of things. Unfortunately, Wassim has moved on and while I retain a keen interest in PDE and Code 9 funds some of the work, the project is not getting a lot of focus from me.  This change is a major bonus for the project.

on Oct 9th, 2008Building Platforms

A little while ago Martin Lippert and I chatted about platforms, how to build them, API and a mess of other stuff.  Martin recorded the session and has put it up on SE RadioCheck it out.

on Oct 8th, 2008Tip: Eclipse, OSGi and Execution Environments

I was working with a client recently and the question of what are execution environments came up. Execution environments (EEs) are simply symbolic representations of JREs. For example, rather than talking about a specific JRE (with a specific name at a specific location on your disk), you can talk about the J2SE-1.4 execution environment. This way things can be shared without referencing specific paths. Furthermore, tools like PDE help setup your classpath compliance settings base on the EE you’re working with (on a per bundle basis).

Ok, the reason the question about EEs came up was because of this screenshot:

What’s this screenshot show? Well, the client was interested in using a Base64 encoder so why not use one from the VM? At first, the comedian in me thought why not use one of the 20 we have in the SDK already?

Ok, maybe that’s a little of an exaggeration :)

Back to the problem at hand… in the beginning, things were OK… it wasn’t until the move to Eclipse 3.4 and the client updated his bundle to take advantage of execution environments. By selecting an execution environment, the client had his classpath updated and access rules were set on what packages are visible to the plug-in. Great! But why get the access restiction on the ’sun.misc’ package? OSGi bundles can clearly see packages from the VM, this isn’t a problem. The problem is that ’sun.misc’ isn’t a package that is considered to be included VMs (by default). You could imagine this become a problem if you’re bundles are working great on a specific Sun VM, but than people try to run your bundles on another VM that doesn’t have the ’sun.misc’ package available. If you’re curious about what packages are supplied by which execution environment, see the OSGi compendium specification (999) and take a peak into the Equinox profile files (i.e., J2SE-1.4).

How do you solve this type of problem? Well, you have a couple options. The first, you can make OSGi aware of a package like ’sun.misc’ by setting a system property before launching:

-Dosgi.framework.extensions=sun.misc

The other option is to create a new bundle that simply exports what is available in the VM and have your bundles depend on that if they need the specific package. There are other ways to get around this issue but generally the first option is the preferred route. Both of these options should make the tooling happy. However, don’t be tempted to do this frequently as usually doing this is a sign that your bundles aren’t VM independent.

Oh, another tip… if you’re looking at debugging where packages are being wired from, PDE includes a nice Plug-in Dependencies view to help you with this:

Using this view, I can tell where my imported packages are coming from while I’m developing. For example, it’s easy to see if you’re getting a package from the VM for free or from some plug-in.

Hope this tip helps and happy hacking!

on Oct 3rd, 2008Tip: Spellchecking in Eclipse

Ever wanted to add spelling checking to a dialog, form or some editor in your Eclipse-based application?

Well, I needed to do this recently for a project and thought I would share with people how it can be done (also, I had people emailing me to write more tips ;p). The spell checking infrastructure in Eclipse is handled by the text editor framework. Speficially, there’s an extension point where you can add your own spellchecking engines if you so desire:

The Java Development Tools (JDT) provides an engine by default that gets activated for things like java source files, properties files and ‘text’ files. To take advantage of this functionality, we need to hook into the text editing framework inside of Eclipse. I’ve provided a simple example to show you how you can do it, but here are the basics:

...
final SourceViewer sourceViewer = new SourceViewer(composite, null, null, true, SWT.MULTI | SWT.V_SCROLL | SWT.WRAP);
// grab the text widget from the source viewer
StyledText fTextField = sourceViewer.getTextWidget();
// this is where the magic happens for spellchecking
// see TextSourceViewerConfiguration#getReconciler
Document document = new Document(text);
SourceViewerConfiguration config =
     new TextSourceViewerConfiguration(EditorsUI.getPreferenceStore());
sourceViewer.configure(config);
sourceViewer.setDocument(document, annotationModel);
...

If you ever have written an editor within Eclipse, this code should look familiar to you. If not, well, welcome to text editing framework within Eclipse. You’ll notice that by default, everything is spellchecked. This is because of how the TextSourceViewerConfiguration sets up reconciliation by default (see getReconciler):

...
SpellingService spellingService= EditorsUI.getSpellingService();
IReconcilingStrategy strategy= new SpellingReconcileStrategy(sourceViewer, spellingService);
MonoReconciler reconciler= new MonoReconciler(strategy, false);
...

If you need to only spellcheck certain areas of a document, like say comment headers, you need to provide your own reconciler and partitions. Than you need to setup your partitions that you want to have a spellchecking strategy (SpellingReconcileStrategy) associated with.

I hope this helps and here is the code used in this tip if you’re interested.