Tag: eclipse

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 “com.ibm.rcp.site.anchor.shared.feature” 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.

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") {
      @Override
      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;
      }
   }.schedule();

   // wait for job to complete (Queue.take() wont return until
   // the job puts something in the queue)
   try {
      queue.take();
   } 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.