Git Flow, Maven, ODA and Domino FP8

The last few weeks quite a large amount of my work has been outside the NSF, so using more standard development tools in a more standard environment. There have been some challenges but also some refreshing experiences.

Git Flow

One of the big challenges for traditional Domino development is when features are requested but cancelled or fixes are required to live code while new features are in test. Fortunately, I decided from the start to do the REST service I was working on as an OSGi plugin using JAX-RS rather than try to code in an NSF or use Extension Library components. So I was just using a plugin project (I’m not confident enough in the Maven/Tycho dance to go with a mavenised OSGi plugin project) in Eclipse. Eclipse has the XPages SDK as well as Extension Library and ODA source projects and a debug configuration for my local Domino server. The debug configuration means my Domino server has a pde.launch.ini configuration in <Domino>\data\domino\workspace that tells it to look to my Eclipse debug configuration for any plugins to launch when HTTP starts up, so I’m live-coding against my Domino server. And the projects are git-enabled with git flow as well, accessed via SourceTree. That means if a new feature is required, I create a feature branch, and if it’s not needed I just switch back to my develop branch and create a new feature from there for the next change. And if a fix is enabled on live, I create a hotfix branch which is based on the master branch, and it doesn’t mean live gets polluted with unapproved changes. This is a refreshing change. And my Domino server is instantly picking up whichever branch I’m working on. Plus SourceTree means it’s easy for me to see the diagram of the various branches and commits.

Yes, this is possible with XPages NSFs, but because automatic sync-ing does not seem totally robust (multiple applications touching the same files) and issues with metadata being exported (although better Swiper integration is slated for feature pack 8 Designer client), it’s not as nice.

But one challenge I’ve had has been switching branches and having uncomitted changes that have been left over from the other branch. Trying a git “hard reset” to a commit doesn’t always quash them and I also had situations where trying to stash the changes left them there too. The solution I found on the internet seemed drastic and scary (and would be a lot harder with an NSF involved!), which was to delete everything except the “.git” folder in the local repository, then do a hard reset to the relevant commit. The only downside is that it seems to leave empty project folders in Eclipse, so it’s a case of deleting the projects from Eclipse and re-importing them. That’s what I’ve had to do a number of times with ODA.

The reason for this is I’ve been using ODA against Domino FP8 (preliminary release notes have been published, though Barry Rosen has confirmed this does not include all features). But at the same time, for my session at IBM Connect next month, I’ve been making some additions to the core. So I need to keep switching between branches. I can’t give any specifics, but the good news is we’re expecting to be able to hit the ground running with ODA when FP8 is released (it’s currently at stage 3, Gold Candidate, so getting closer).

As part of my development, I’ve also needed to push those changes to develop from my private FP8 branch – don’t bother looking, it’s not on OpenNTF Stash or GitHub ;-). But the develop branch then needs building and I need a copy of the output for other internal servers and customer environments. Thankfully, OpenNTF has an infrastructure for that. Jesse Gallagher has set up the develop branch to automatically build using OpenNTF’s Bamboo. So I can see the build, see it’s successful (at this point I’m not fully sure how to create JUnit tests against Domino during an automated build, so there aren’t any configured). But on OpenNTF’s Artifactory I can then access the completed build for deployment.

Artifactory also came in useful when I have been developing the ODA demo database, which is a Vaadin web application and is mavenised (because using Maven is much more straightforward with a web app and with Vaadin). However, as soon as I included any ODA classes, it caused problems getting Maven to build it. That because a bigger problem when trying to add additional Vaadin add-ons. Jesse pointed out that I can add Artifactory as an additional repository, and ODA classes now compile happily.

I had an additional challenge that it still looks for lotus.domino classes. Thankfully I found I can add a reference in the pom.xml to a specific jar, choosing a groupId, artifactId and version I decide on, setting the scope to “system” and pointing to the location of the Notes.jar file on my file system. I should also be able to do the same for the CrossWorlds classes referenced in my Filter and Listener, although a Maven build works fine while I’m developing with just removing those Java classes. And after IBM Connect, I hope I won’t need that because I’ll be able to use the clever work Daniele Vistalli and Matteo Bisi are presenting at IBM Connect with Domino and Docker.

(By the way, I’m just using CrossWorlds for easier development because of Maven. As before, the demo application will also be available as an OSGi plugin web application.)

This blog post is as much a brain-dump, so Google can index the solutions I’ve used and I can free up my memory for new learning. And although I know I’m ahead of many Domino developers, I’m way behind most web developers and thankfully some in the community have supported my bungling fumbles as I struggle through the mud!

XPages has brought developers significantly closer to standard web development approaches and tools. But there are still areas where integrating Domino into that landscape is a challenge. Nonetheless, Domino still has a great deal to offer and some significant benefits over alternate elements in a stack. It’s untangling that stack that can be tricky.