I’m in the process of transitioning from Domino agents to DOTS tasklets and my first goal would be to educate myself to such technology.
To be honest, although exciting, I’m actually finding it frustrating. Information is scattered and I feel like I’m composing a puzzle without clearly understanding where I can find all the pieces and which fit and which don’t.
Right from the start preparing a development environment and writing the first tasklet can lead to subpar results because of the patterns I’m suggested to follow.
An example of this, after having prepared the development environment, is to reference the Notes.jar archive to allow eclipse to both successfully compile the code and export the plugin (granted I’m developing one that invokes lotus.domino classes).
So, I had initially come across this presentation:
Meet the Java Application Server You Already Own – IBM® Domino®
To handle the such issue there it’s said to import the jar, define it at runtime and export all of its packages. Here the 3 steps in sequence:
That would actually do it… if it only weren’t for a side effect that isn’t mentioned and that would have me end up with the Notes.jar duplicated for each plugin/tasklet I develop both in my eclipse workspace and in each plugin exported that is going to be as big as the code I developed plus the size of the Notes.jar I imported.
Two things:
- Exporting the packages in a first tasklet scenario is an unnecessary step. It’s useful only when we want to have the plugin we are developing used by other plugins that need access to our classes.
- If I really don’t want to have the Notes.jar file within my plugin excluding it for export is a step that must be taken because by default such resource would be exported. See screenshot below.
However, there’s definitively a better approach to that. And I discovered it by reading another DOTS document:
Starting from slide 24 it gives a hint of how things should work but it doesn’t tell me how and above all fails to tell me why
By following such instructions I ended up with the thing not working. At this point I started wondering why. I realized giving the wrapped Notes.jar plugin such a meaningful name (com.ibm.notes.java.api) had to mean something. So I scrolled through all the packages that make the OSGi target platform and one entry caught my attention, an entry that appeared as soon as I was defining the lotus.domino dependency:
The “funny” thing is that it mostly looked like an empty file and having a slightly different name from the one suggested above. I took my chances and renamed my plugin project from com.ibm.notes.java.api to com.ibm.domino.java.api. That pulled it off. The plugin in my workspace got automatically loaded and replaced the default kind-of-empty jar. See screenshot below:
I think the steps I mentioned make the correct procedure for consistently developing DOTS plugins while referencing Notes.jar classes without duplicating the file itself.