Tag: expeditor

Developing plugins for IBM Notes on Mac

I’ve been developing plugins for IBM Notes on Mac for years now but never really got around to sharing the steps on the blog. The below steps – in very crude form – works with Java 8 on Mac OS El Capitan (v. 10.11) using IBM Notes 9.0.1. The below sections are additions to the regular steps on creating a target platform documented otherwise on this blog

Main-tab

Run a product: com.ibm.notes.branding.notes

Execution Envionment: JavaSE-1.6

Arguments-tab

Program arguments:

-personality com.ibm.rcp.platform.personality
-debug
-console
-ws cocoa

VM Arguments:

-Declipse.registry.nulltoken=true
-Djava.util.logging.config.class=com.ibm.rcp.core.internal.logger.boot.LoggerConfig
-Dcom.ibm.pvc.webcontainer.port=8080
-Declipse.pluginCustomization="/Applications/IBM Notes.app/Contents/MacOS/rcp/plugin_customization.ini"
-Djava.protocol.handler.pkgs=com.ibm.net.ssl.www.protocol
-Dosgi.hook.configurators.exclude=org.eclipse.core.runtime.internal.adaptor.EclipseLogHook
-Dosgi.framework.extensions=com.ibm.rcp.core.logger.frameworkhook
-Xbootclasspath/a:"/Applications/IBM Notes.app/Contents/MacOS/rcp/eclipse/plugins/com.ibm.rcp.base_${rcp.base_version}/rcpbootcp.jar"
-XstartOnFirstThread

Environment-tab

  • DYLD_LIBRARY_PATH=/Applications/IBM Notes.app/Contents/MacOS
  • NOTESBIN=/Applications/IBM Notes.app/Contents/MacOS

Notes / Eclipse / Lotus Expeditor mapping

Developing plug-ins for Lotus Notes or Expeditor can be complicated enough but you also have to look out for platform differences and the difference in capabilities between different Notes/Expeditor/Eclipse versions. To make this easier for myself I’ve started compiling a Notes version to Eclipse version to Expeditor version mapping table (Notes / Eclipse / Lotus Expeditor mapping).

If you know one of the missing versions please let me know so the table may be complete and be a good reference for us all.

Tip for improving Notes startup time from Eclipse

On Tuesday I was contacted by a fellow Yellow-head concerning my Lotusphere 2009 demos and the startup time of Notes from Eclipse. The demos had nothing to do with it – the issue was with his Eclipse setup and was easy to fix.

He was experiencing that it took minutes to launch Notes from Eclipse which made development very frustrating and time consuming. He was using Eclipse configured through Lotus Expeditor Toolkit which made me take special notice as this could be a general problem and something many may/will experience.

After discussing his setup for a while I thought a little about it to tried and think of what could slow down Notes startup. One of the first things I could think of was that he might (inadvertently) be clearing his Eclipse workspace very time he launched Notes. This operation is time consuming and it turned out to be the case. After correcting this he was down to launch times in order of seconds which is also what I experience.

The Eclipse workspace contains all your Eclipse settings as well as a persistent registry of the plug-ins installed on the platform as well as their dependencies. This dependency graph takes a while to put together as it requires reading through all the plug-in manifests and trying to resolve the dependencies specified there. So as you can imagine clearing the workspace before each launch of Notes will take unnecessarily long. If no plug-ins are added to the core platform it doesn’t make any sense to recalculate this dependency graph.

To make sure you don’t clear your workspace when launching Notes from Eclipse do as follows:

  1. Open the launch configuration settings (select “RunRun Configurations…” from the menus)
  2. Select your Notes launch configuration (probably named “Notes” or similar)
  3. On the “Main”-tab take a look at the “Workspace Data”-section at the top. Make sure there isn’t a checkmark in the “Clear” ckecbox. If there is, remove it and apply the changes.

That’s all there is to it.

Installing Lotus Expeditor Toolkit 6.2 – there’s an issue with the instructions

In preparation for my Lotusphere session I installed Lotus Expeditor toolkit 6.2 on top of a clean Eclipse 3.4 install in order to test it out. One of the things I noticed was that there is an error in the install guidelines – not critical but if you’re new to Eclipse you might be stumped. The documentation also fails to mention how to configure the Toolkit once installed. Read on…

The error is in the doc/index.html in step 5 where it states

"Select Add Site and browse to the drive
and directory where the Lotus Expeditor
Toolkit update site zip file is located
and click OK."

The problem is that the Expeditor toolkit that I downloaded from IBM Partnerworld didn’t have a zip-file but instead an unpacked update site. In my case step 5 should instead be

"Select Add Site and browse to the drive
and directory where you unpacked the Lotus
Expeditor Toolkit and select the
Expeditor_Toolkit_install directory and
click OK."

The remaining steps are fine and installing the toolkit is almost easy… There is one caveat the documentation fails to mention and that’s how to fill in the dialog that pops up once the Toolkit has been installed and Eclipse has been restarted. I fill in the dialog as follows (with Notes 8.5 installed in C:Program FilesNotes 8):

  • Lotus Notes 8
  • C:Program FilesNotes8frameworkrcpeclipse
  • jre6
  • 1.5
  • Display the first time a new workspace opens

SWT @ Notes 8: Network awareness from SWT components

One of the big strengths of having Notes 8 built in Lotus Expeditor is that you have access to all the functionality of the underlying Expeditor platform including its services. On if the nice ones is that you can be notified when the underlying network connectivity is available and/or unavailable.

A call to action for all non-US developers!

In my post titled “XPD – where do you live?” from the other day I discussed some problems with i18n (internationalisation) of applications developed in Java for the Notes 8+ platform using the built-in classes (java.util.Locale). Since that post I have been in dialog with IBM via the Domino NEXT Design Partner program.

It has been confirmed that this is indeed a problem and probably in the core Notes client. The problem probably stems from Lotus Expeditor.

Unfortunately not much light has been shed on the subject except IBM asking me to run a Danish Notes client which is among the worst thing I could imagine doing. I run software in English – period! I do however expect the software I run to be able to detect my computer locale as set in the operating system. As an aside it is actually quite common for non-English speaking Europeans to run English software despite the fact that a native-language edition is available.

As part of this process I have been thinking about the API’s that we need to have available for i18n. It is quite clear that we need

  • the possibility to obtain the language (as a java.util.Locale) of the client itself (that is the language of the menus etc.)
  • a way to obtain the java.util.Locale the OS is configured for
  • an official API for accessing the regional settings as configured in the Preferences for the calendar display in Mail

If we had these we should be able to create the kinds of localized products and plugins customers expect and demand.

What is your take? Can you see more API’s we need while we’re at it?

XPD – where do you live?

Disclaimer: I’m trying to get some info from IBM on this subject so please check back as I will update this post as more info becomes available…

Again this is one of those posts that will annoy the heck out of European developers…

Internationalisation – or i18n – is done using the java.util.Locale class in Java. When calling Locale.getDefault() the standard Locale for the JVM should be returned and should be da_DK for me (country: Denmark, language: Danish), en_US for you US guys (country: USA, language: English) and de_AT for people from Austria (Country: Austria, language: German). The Locale can be supplied to many localisation sensitive classes such as java.util.Calendar etc. to make sure it works as expected for the current user locale. Most times however you don’t supply the locale explicitly which will make the platform do a Locale.getDefault() for the current locale.

Meet Lotus Notes 8+…

Per default Lotus Notes 8+ runs with a Locale of en_US which is great if you’re based in the USA and speak English or simply only use the built-in functionality of Lotus Notes. If you’re a plugin developer and you do any i18n work you will be sadly disappointed since Calendar and ResouceBundle will be broken. Since Locale.getDefault() returns en_US you will get back a Calendar for the US (e.g. Sunday is first day of the week) and English strings from your resource bundles.

Maybe this is why the preference has a page for locale setup (see File/Preferences/Calendar and To Do/Regional Settings) which is used by Mail.

To makes matters worse I think it’s a core platform issue since you can actually change the language of your Notes client by supplying a command line argument (-nl) to the Notes client. Doing this (-nl da / -nl da_DK) changes the menu item text in my Notes client but any plugin that use Locale.getDefault() still return an incorrect result as shown on the image below.

To make it even weirder it works as expected when the Notes client is started from the Eclipse IDE using “-nl da_DK”. Go figure!



(click on the image for larger version)

This behavior has been verified with Notes 8.0.1, Notes 8.0.2 and Notes 8.5 beta 2.

Why patching the org.apache.commons.lang plugin is necessary

As part of the core Lotus Expeditor framework a number of Apache Jakarta Commons libraries are supplied as plugins. Unfortunately the org.apache.commons.lang plugin is incorrectly packaged which means that developers cannot reuse code from this library. This goes for all Notes 8 releases so far (Notes 8.0, 8.0.1, 8.0.2 beta 1, 8.0.2 beta 2, 8.5 beta 1).

The problem is that the plugin manifest file (MANIFEST.MF) doesn’t export all the packages of the library but only the root package. The *right* thing would be to export all the packages (e.g. org.apache.commons.lang.exception, org.apache.commons.lang.math etc.)

Luckily the problem is quite easy to fix and it will be in upcoming releases. For now, as a developer, the easy way to solve the problem is to simply modify the manifest by unzipping the plugin, changing the MANIFEST.MF file and rezipping the plugin back up. I have done this on all my machines and will be supplying a patched version of the plugins so you can run TwitNotes 1.0.5 on these releases.

Patching this plug-in wont affect other code in my eyes.