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.

“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!

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?

• Monday
  • Anyone up for dinner or frosty beverages? Please email me!
• Tuesday
  • RT Symposium
  • e4 Symposium
• Wednesday
  • What’s new in Plug-in Development? - Chris Aniszczyk
  • Service Discovery and Remote Services using ECF - Scott Lewis
  • Eclipse Project Update - Jeff McAffer
  • Best Practices for Equinox and OSGi - Jeff McAffer
  • RT Project Demo - Jeff McAffer
• Thursday
  • API Tooling in Eclipse - Chris Aniszczyk
  • ECF Inside and Out - Scott Lewis
  • Equinox p2: provisioning your world - Jeff McAffer
• Friday
  • Anyone up for dinner or frosty beverages? Please email me!

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!

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.

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.

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!

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.