**SHAMELESS PLUG:** With me moving to HCL next month, it's always important to ensure there is sufficient resiliency in the development teams of open source projects. There are always areas where OpenNTF Domino API may be of benefit, but there will be projects I'm involved in where it won't. There will also be a big pull on my personal time for other new open source projects. So now is the time to get involved. If there's an open source project I've worked on that you rely on, if you feel you can help or want to get the knowledge to help, reach out to me.
As a consumer, when upgrading Domino that uses ODA, you often don't need to do much. Yes, it's always advisable to stay on the latest releases of dependencies. But typically older update sites will continue to work, you just don't have access to newer classes or methods. The caveat there is around Domino 9.0.1 FP10 through 10.0.1, where some cleanup was done of the Domino server to remove unnecessary plugins and we had not yet removed old, unused references to them from ODA.
But from a development standpoint, whenever there are new versions of Domino, there is always some work we have to do to support the version. There are always new methods, and we have to add them to ODA, typically just calling the relevant lotus.domino methods. Then it's a case of building a snapshot release. This is where the bigger challenge comes.
The compile process uses the Java build path and the installed JRE. This points to core Domino jar files, like Notes.jar. But building gets more complex. The build process uses Maven. It needs access to those jars, but as Maven artifacts or as a p2 repository, which is how we use it. Way back in the Domino 8.5.x timeframe, IBM provided that as a package we could use. But we stopped getting that. Generating it took a lot of knowledge of Maven and OSGi, but thankfully Christian Guedemann and Jesse Gallagher built and maintained a tool to generate those files, on OpenNTF's GitHub.
For full releases of Domino, that works nicely, though you need to understand what you need and be comfortable with Maven commands on the command line. But people want projects like ODA ready at day one. So we also need to run it with betas. However, the version numbers provided with betas have a different format to handle more frequent releases. Getting that to work seamlessly and anticipate all scenarios is a challenge. So sooner or later, things break.
Troubleshooting
The generation of the p2 repository - typically mine is saved at C:\UpdateSite - generally doesn't error. It's using it that fails, because it's not been generated in a format Maven can then use. The error therefore isn't in the project you're building at the time, it's in the output from the generate-domino-update-site command, the content.jar in C:\UpdateSite.
If you don't panic, Maven tells you how to troubleshoot: Call mvn install -X, the final parameter being full debug. With that, yesterday, I got this error:
A bit of lateral thinking, comparing to working versions and a bit of knowledge of OSGi plugin versions brought me to a hypothesis: that it was failing because there were too many dots in the version number. Thankfully Jesse was able to point me to the right place in the code for this. Trying to change everything to underscores didn't work - it expects a format with XXX.XXX.XXXXX and not underscores there. But changing this line to use an underscore and remove the "-1500" from the end solved it. The latter step may not have been needed, but the result was a version number that only had three dots in it.
There's some fairly deep Java knowledge here, but this highlights the need for breadth of understanding in order to ensure projects way down the chain don't break. But building the p2 repository at C:\UpdateSite is not something done often, so it's easy for knowledge the gets lost as a consumer. Hopefully this blog post will help me remember.
