CODEWITHSUNDEEP
lotus-notesdomino-designer-eclipse
Tinus Riyanto
Tinus Riyanto

Reputation: 21

Using Headless Domino Designer to create NSF on a Domino Server

This wiki (https://www-10.lotus.com/ldd/ddwiki.nsf/dx/Headless_Designer_Wiki) seemed to indicate that you can only create NSF under your Notes Data directory. I have done a couple of quick test and the only workaround I can find is to install Domino Designer on the same server as the target Domino server and set the target as the Domino data folder (i.e: C:\Domino\Data\sample.nsf instead of just sample.nsf).

The reason for this is I am trying to find an automated way of the following operation

  1. Import ODP into workspace
  2. Associate with a new NSF, but choose a Domino Server as a target

Does anyone have other workaround for this ?

Upvotes: 1

Views: 331

Answers (1)

Eric McCormick
Eric McCormick

Reputation: 2733

I wish I had a more complete answer for you, but as this is still unanswered after a few days, I'll try to add some insight. It sounds like you have some experience getting headless DDE builds to work, so I won't focus on that. If you're looking for my take on headless DDE builds, I blogged on the subject a while ago, but since adapted the Jenkins CI based process I outlined there for a GitLab CI runner based solution, which I described in another SO answer.

Firstly, I would strongly recommend against setting your Designer target as the same as a server instance. This might work, but seems an unnecessary complication, and potentially issue prone, IMO.

My interpretation of your steps:

  1. automatically receive updates (e.g.- on master branch, or all commits, etc.)
  2. perform build via headless DDE
  3. deploy built NSF

Splitting apart the logic for deploying of the built NSF is ideal here, since you have an asset that needs to be parked in a server path. The two main approaches I see are either:

  • having a dev/staging server that you can programmatically restart on demand
  • a more complex mechanism, in an NSF or server plugin, that will ingest the NSF's design and replace the design elements in a (newly created) destination NSF

As you can imagine, that last one is a bit tricky, but it was something I've left off working on, until I have more "free time". As for the former, you'll likely want someone with a bit of admin/operations skills set assist you, but in my mind there would be a total of three scripts involved:

  • one to down the destination server (this is why it should be a dev/staging server)
  • one to copy the built NSF to the destination file system path
  • one to start up the destination server

If you have a design task set to run at a certain interval and point the staging server for any changes, you could conceivable pull from that at whatever your interval is; nightly, etc. I hope the perspective helps.

Upvotes: 2

Related Questions