Configure Eclipse 4.2 (Juno) for Notes 9

Yesterday after publishing my updated article on configuring Eclipse 3.5 for Notes 9 I wondered why I was still using such an old Eclipse build. Now Lotus Expeditor and hence Notes is still based on Eclipse 3.4 but since we develop for what’s called a target platform that shouldn’t matter so I wanted to move to Eclipse 4. So I grabbed Eclipse 4.2 (Juno) from and started configuring (of course capturing what I learned). The steps are actually remarkably similar to Eclipse 3.5 (with some slight changes) so now I’m using a new Eclipse build with all the functionality benefits (the New and Noteworty page outlines many nice features) it provides plus the updated look’n’feel.

I’ve captured the steps into a new page called Configure Eclipse 4.2 for Notes 9. The page also contains a video walkthrough now (rather rough) but it shows what’s involved. The video is about 5 minutes long.

Happy coding.

Configure Eclipse 3.5 for Notes 9

Next after upgrading my Notes client to IBM Notes 9 I updated my Eclipse environment to use Notes 9. The steps are basically the same as previously but for good measure I updates my guidelines. The document is now titled Configure Eclipse 3.5 for Notes 9. For those in the know the only thing to update is the install_id (now “135548059835”) and the rcp.base_version (now “”).

Happy coding.

Controlling the feature install location

When installing plugins (that is Eclipse features) into Lotus Notes and you’re running a roaming environment you kind of have a problem. The problem is that the only part of the plugins that roam are the plugin settings (i.e. should the Sametime come of front on new IMs) but not the actual code for the plugin. That means that when a user roams to a new machine the plugin isn’t installed and hence the user will experience that the plugin will start installing and prompt for a restart. This is because plugins are installed in what’s termed the “user” location (ie. your workspace directory) and not in a shared location.

An alternative is to install the plugins in the “shared” location instead (on my laptop that would mean that features would go into C:Notes8frameworksharedeclipsefeatures instead of C:Notes8dataworkspaceapplicationseclipsefeatures). The “Controlling the feature install location” article from the Lotus Expeditor info center has a nice description on the 3 possible locations.

To do this you use what’s called the colocation affinity of a feature and specify that in the feature.xml describing the feature (the feature.xml can be found inside the jar-file that makes up a feature). To do this you have two options – 1) edit the existing feature.xml and set the “colocation-affinity”-attribute of the top level “feature”-tag or 2) set it using the GUI editor when you build your feature. Option 2 is for those doing their own plugins and option 1 for those changing the colocation affinity for a 3rd party plugin.

Below is a screenshot of setting the colocation affinity to “” driving the feature to the shared location using the GUI editor in Eclipse.

Please note that installing into the shared location require read/write access in the file system for that location.

Using a queue to wait for a job to complete

A question I get often is how to perform an operation synchronously (that is blocking) instead of asynchronously when developing plugins. The question stems from the fact that most operations are done using the Job-framework where code is run in a background thread. But what if you need the result before continuing. What if you don’t want to wait or the code doesn’t lend itself to that approach?

I find that the easiest way (without resorting to Job scheduling rules) is to use the java.util.concurrent classes to make the calling thread wait for the Job to complete. This approach works for all job-types including Notes based operations using NotesSessionJob.

Code could look like this:

import java.util.concurrent.ArrayBlockingQueue;

public FeedLoader() {
   // define queue to hold a maximum of 1 element
   final ArrayBlockingQueue<Object> queue =
      new ArrayBlockingQueue<Object>(1);

   // create and schedule job
   new NotesSessionJob("Getting Notes username") {
      protected IStatus runInNotesThread(Session session,
       IProgressMonitor monitor)
       throws NotesException {
         // perform operation and store result
         FeedLoader.this.username = session.getUserName();

         // put stuff in the queue to signal we're done (we
         // could also have used the queue to return the value)
         queue.offer(new Object());

         // return
         return Status.OK_STATUS;

   // wait for job to complete (Queue.take() wont return until
   // the job puts something in the queue)
   try {
   } catch (Throwable t) {}

I’m sure there are other, and probably easier and better, ways to do it but this is how I often do it.

Developing an Eclipse plug-in from start to finish

Ryan Baxter from IBM who I had the honor of co-presenting with at Lotusphere just published a new article on the appdev wiki titled Developing an Eclipse plug-in from start to finish. The article takes you step-by-step through building a nice plugin and uses the Eclipse WindowBuilder (GUI editor) for taking the hassle out of building the UI.

A very nice Friday read.

Intelligent recommendations

Just came across the new code.recommenders incubation project over at and wow does that look cool. Very cool indeed especially if you spend part of your day in Eclipse. Actually the uses for this goes beyond code completion just like Mylyn goes beyond code as well (see Imagine combining this with Notes 8!). Imagine this for email addressing and/or collaboration. Think how analytics technology like this could make “recent contacts” so much better. Imagine how spell check could be improved.