After a couple of days deep in XPages development (more on that shortly), I surfaced again to read Oliver Busse’s blog post about development IDEs. He makes some very salient points, but there is a more critical pre-requisite that’s not mentioned – source control, or rather DXL round-tripping.
The root of the issue about development IDEs is a critical difference between Domino and other development platforms. Most other types of development – Spring Boot, Vaadin, Vert.x, generic Java, Node.js – works from flat files. These are compiled and potentially packaged up with some kind of packager and deployed. Java compiles every time you save, so it’s easy to miss that step. The main part of the IDE build for Java development is creating a .class file that most IDEs hide, because you don’t need to see it. Maven can perform automated tasks during the build process and also package up as e.g. a jar or war file. Alternatively, the Java code may be run without a packaging process. I use this all the time with plugin development, loading the plugin directly from Eclipse with my Domino server. I just save and restart HTTP, no build required. Hot swapping of Java code with something like JRebel can also auto-deploy. With Node.js npm build does that building, typically compiling the code for various browsers with something like Babel. Both npm and Maven also have an install command to download and install all dependencies, so they actually do both ends of the process.
Dependency management is not something Domino handles. And outside of XPages, it’s not something developers come across. The build process doesn’t really happen outside XPages and many developers are probably unaware of what it’s actually doing. It’s taking the XML in XPages and Custom Controls, then converting them into Java classes (in the “Local” folder in Package Explorer) and building class files.
But there’s one critical additional step it’s doing. Storing them as design notes in the NSF. With jars or wars, the packaged code contains files that are the same as are available in the IDE (a jar file can be unzipped to see the .class files, MANIFEST.MF etc in it). With Domino, what’s in the NSF is not the same as in source control. To move them into the NSF there is some kind of conversion required, to create DXL that is stored in a Design Note.
This DXL round-tripping – from flat file to design note to flat file – is the main reason standard source control has not been used for traditional Domino development. There are some instances where fidelity is not kept, not to mention the quirk of whether DXL is stored in flat files as binary data (of no use outside Domino Designer, because it’s unreadable) or not. Unless you’re talking about basic development of text-based design elements, faithful round-tripping is a critical requirement for working outside of Domino Designer.
ODA allows some of that to be done, which is how I created NSFs including design notes on-the-fly for IBM Think 2018. This is also what needs to be done for a Node.js design package. But ODA’s work is just about views really – anything other “design elements” would be stored outside of Domino and outside the NSF. Jesse has also done some work, but I suspect it’s also limited to basic design elements, for the same reason – DXL round-tripping.
So if you’re looking for a choice beyond Domino Designer for NSF-based development or a single source control approach for all your development, you really need to be voting for this idea. It’s a key pre-requisite for any discussion on IDEs.
Voted (already did that a long time ago). I think that something like Swiper also needs to be done, since the ‘extra’ information available in a Notes design note like creation date and modification date mayis not always relevant to the actual design information.