Use XspLibrary (OSGI plugin) in Domino Designer

1
votes

I've build an osgi plug-in to wrap existing jar files. I've been following this guide.

After building the plug-in I deploy it via an update site. I use a widget to import the plug-in into the domino designer.

In "File > Application > Application Management" I can verify that the plug-in is loaded (i.e. it shows up under /workspace/applications/eclipse)

Now I build a new nsf and I can select my plug-in as a Xsp library in the xsp properties. Then it starts to act strange: I can use all exported classes from the plug-in only if I open then plug-in project in the domino designer, too.

If I close the plug-in project I get two compile errors:

  1. "StringUtils cannot be resolved"
  2. "The import org.apache.commons.lang3 cannot be resolved"

Sometimes I also get the following error:

  • "The project was not build since the build path is incomplete. Cannot find the class file for ...."

Does anybody now why these errors occur? As I already mentioned: opening the plug-in project in the designer resolves all errors.

Yours Detlef

2
osgixpages
are you able to "import" the plug-in in the xsp.properties file? I was not even able to do that. – Greg
Yes I can select the plug-in in the xsp.properties file. Adding the plug-in to the xsp properties works whether the plug-in project is open or not. – Detlef Birkholz
Hi Detlef. Interesting observations. I'll have to look into that in more details - when writing the article I didn't do anything special with the plugin project (and it is in another working set) so Designer may just have "helped" me without I realized it.... – John Dalsgaard
Hi John - If you were developing the Plugin project in Designer and the project was open, it would be in your current 'workspace' which is an eclipse concept. So when designer (eclipse PDE) tries to resolve your plugin dependency for your XPages app, it finds it in your current 'workspace' (does not matter if it is in a different working set) instead of looking in the installed designer plugins. This means it can successfully find the commons.lang3 jar from there. If you close the plugin project (right-click in package explorer close project) it should then use your installed plugins instead. – Cameron Gregor

2 Answers

3
votes

You need to have the plugin 'unpack' after installation, at the moment your wrapped jars are hiding within your plugin jar. they need to be unpacked for Domino Designer to use them.

Presumably you created a feature project to install the plugin? Go back to the feature project, and the Plug-ins list, select the plugin and then tick the check-box next to 'Unpack the plug-in archive after the installation'

In your update site, clear out your previously built plugins and features and then re-build this new feature into the update site.

Before installing the new version of the feature it might be a good idea to Uninstall your old version in designer: File -> Application -> Application Management Then select the feature in the left pane, and then uninstall from the available tasks in the right pane.

Then re-install from your newly built update site, (or via widget deployment as you did before)

After your installation you can inspect the file system location of where your plugins install to: 

<NotesData>/workspace/applications/eclipse/plugins

and verify that the plugin has been un-jarred into a folder instead of being just a jar.

Also, in the Package explorer, if you then open up your XPages application that is using your XspLibrary/Plugin, you should be able to see your plugin in the list of plug-in dependancies, and the icon next to your plugin should be a folder and not a 'jar' icon

0
votes

Both errors mean that you need to install a dependency of xsplibrary namely apache commons lang 3.x. It is available as an OSGi bundle so you can simply add it to the target platform.