Today Notes and Domino Feature Pack was released. It’s good to see a developer-heavy release finally delivered. Apart from the Extension Library on OpenNTF, developers have had little to engage their interest over the last three years. But FP8 is a marquee release for developers and app dev server users.
The most noteworthy point for XPages developers is that the latest Extension Library release has been rolled back into the core, including the Name Picker, Value Picker and other features I’ve contributed to Extension Library over the last couple of years. This can be seen both for the server (<Domino>\osgi\shared\eclipse\plugins folder) and for Designer Designer (<Notes>\framework\shared\eclipse\plugins folder) with versions that are called com.ibm.xsp….._9.0.1_v08_00_20170228-0813.jar.
However, if you rely on Domino Designer local preview, you will need to copy all those plugins, because Designer local preview looks to <Notes>\osgi\shared\eclipse\plugins folder instead. It’s a shame this was missed because it’s not the first time plugins have been missed and was one of the first things I checked when installing the client beta in the middle of January, and I highlighted the omission.
My strong recommendation though it to develop against a local Domino server on your workstation, and I am hopeful IBM will sort out the licensing for at least developers who work for a customer in support. It’s standard for modern web development to have a full local server, it’s the only real way to develop for debugging or plugin development, and I’m not the only one to recommend it. I certainly could never have delivered all the sessions I have promoting IBM software at user groups, Lotusphere and IBM Connect, unless I had a local Domino server.
On the server side, we finally have Java 8 available. It’s currently just available to plugins and web applications, but it means things like OpenNTF Domino API can start to leverage Java 8 classes and syntax. Just in case you don’t believe me, here’s a screenshot of the output from a REST service using the OpenNTF Domino API Starter REST servlet:
The only caveat is that the Execution Environment has to be blank. When you create a new plugin, this will default to e.g JavaSE-1.6 or JavaSE-1.8, like this.
If you leave it like that, the plugin will fail to load and if you diagnose it on the console, you’ll see this message:
To get it to work correctly, you just need to set the JRE to something that uses 1.8 (I’m using XPages SDK, so I set it to my XPages Domino JRE), and remove that Execution Environment from the plugin.xml. Eclipse will give you a warning, but it will compile fine and run fine on the server – as seen from the REST plugin screenshot I showed.
New Classes and ODA
There are a number of new classes, IDVault and UserID, and methods for encryption available. I’ve not really dug into those in detail, but I am sure they will be useful to many.
This obviously has an impact to ODA (OpenNTF Domino API). Because we’re extending the core API, we need to include those new classes and methods in order to compile. What with this and the ability to integrate Java 8, it makes sense to create a firm break – future versions will only support FP8+. We will be releasing ODA 3.2.0 later this week, which will be the last full release to support 9.0.1 up to and including FP8. That will still be available as a branch for any critical fixes, but will not be actively enhanced. Instead, we will promote the new FP8 branch to the develop branch and release version 4.0.0 shortly thereafter which will support 9.0.1 FP8. The branch that supports FP8 is already on Stash, pushed up this afternoon, and I’ve been using it against FP8 beta for some months. (The branch is actually called FP8_1, because I had problems with reverting changes in my original FP8 branch!) If you need an update site release of that, let me know on Twitter / Slack / Skype and I can post it.
ODA REST Plugin Starter Update
Finally, an update on the ODA REST Plugin starter I published on OpenNTF recently. I’ve recently spent time converting it to a Maven project and then into a Maven artifact. What does this mean? Basically, you’ll be able to just choose New > Maven Project, select the Maven artifact (i.e. template), configure things like the package name, contextRoot and url-mapping in the wizard, and get a fully functioning plugin, feature and update site project. When it’s then built with Maven, it will automatically generate a zipped Update Site ready to install on the server. It will basically make setup, development and deployment considerably easier. At the worst, you’ll need to download the Maven artifact, but hopefully we’ll find a way for that to be hosted.
Once I have confirmed the setup on a clean environment, I’ll also create a NotesIn9 showing everything and elaborating on why I think this is my preferred option for a REST service.