Besides working way too much I have spent a good part of my Holidays working on LotusScript.doc version 2 and I'm happy to say that it is very close to completion. I have spent a great deal of time finalizing the logging framework and building the Notes/Java bridge to allow you to run LotusScript.doc from a Notes database instead of as a command line program. I also needed to weed out some issues in this regard which is why I have been blogging issues such as configuring the java.policy file and the maximum Java heap size.

To clarify...

LotusScript.doc v2 is out in a very, very limited prebeta 1 with one person besides me to try and weed out the most serious issues before releasing a beta. Again a beta, at least the first, will only go out to a select number of people to try and keep track of who has what release.

The goals for the functionality of LotusScript.doc v2 are very big but for starters I'm going for feature parity with LotusScript v1. Then once the new technology is out there I'm going to start enabling the new and advanced features.

Thank you for your patience.

Strong: Just to clarify - LotusScript.doc v2 isn't out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

As you might know LotusScript.doc v2 is written in Java instead of LotusScript. This means that you have to make some minor changes to your Notes client to make it work. One of the settings you need to change is the size of the Java heap that is the amount of memory allocated to Java objects.

To change that you need to set the JavaMaxHeapSize notes.ini parameter as described in the Lotus Notes and Domino wiki. Although the wiki describes the setting as only being applicable to Domino servers it works just as fine for my test Notes client (8.0.2 Standard in this case). To change the setting add the following to your notes.ini (do check whether it is already set):

JavaMaxHeapSize=384MB

Strong: Just to clarify - LotusScript.doc v2 isn't out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

LotusScript.doc v2 uses java.util.logging as its underlying logging framework. To spice things up a little it also uses some internal magic to ease troubleshooting and provide easy debugging. One of these tricks is to print out the XPath expression of the element being processed in the log. More on this another time.

In order to use java.util.logging and set custom Handlers and Formatters you need to tweek the java.policy a little bit. It's quite easy as the only thing you have to add to your <Notes binary directory</jvm/lib/security/java.policy file is the following in the first "grant" section:

permission java.util.logging.LoggingPermission "control";

Here is a link to a default java.policy file and a changed java.policy file.

I have spent a little time this weekend trying to create Java script libraries (that is script libraries with Java code and not "JavaScript" libraries) from scratch using DXL. Exporting the DXL of a script library with a jar-file imported into it yields some base64 in a <javaarchive /> tag. The base64 data is however not decodable as it's not valid base64. Base on prior experiences with this kind of stuff I tried decoding the bytes but without success.

The header in base64 is (or at leas to a multiple of 4 characters) is "UEsDBBQACAAIAKyEATkAAAAAAAAAAAAAAAAUAAAA". I guess the beginning is probably a CDFILEHEADER struct (based on prior help) but I'm unable to decode it... :-(

The struct should start with a DSIG struct (16 bit unsigned integer and a 32 bit unsigned integer) but I'm unable to get anything that makes sense. I end up with 20555 for the first WORD but that doesn't "compute". Bummer!

If you've done any work on this and is willing to share please drop me a comment. Thanks.

The extensible nature of Eclipse is simply amazing. I needed a way to look inside a jar-file which is isn't on the build path in Eclipse which isn't "natively" possible with Eclipse. What did I do? I did a quick Google search and 5 minutes later I had JarPlug installed and working. Then after opening this viewpart when selecting any jar-file in the workspace the contents is shown. How nice is that! :-)

In preparation for my Lotusphere session I installed Lotus Expeditor toolkit 6.2 on top of a clean Eclipse 3.4 install in order to test it out. One of the things I noticed was that there is an error in the install guidelines - not critical but if you're new to Eclipse you might be stumped. The documentation also fails to mention how to configure the Toolkit once installed. Read on...

The error is in the doc/index.html in step 5 where it states

"Select Add Site and browse to the drive 
and directory where the Lotus Expeditor 
Toolkit update site zip file is located 
and click OK."

The problem is that the Expeditor toolkit that I downloaded from IBM Partnerworld didn't have a zip-file but instead an unpacked update site. In my case step 5 should instead be

"Select Add Site and browse to the drive 
and directory where you unpacked the Lotus 
Expeditor Toolkit and select the 
Expeditor_Toolkit_install directory and 
click OK."

The remaining steps are fine and installing the toolkit is almost easy... There is one caveat the documentation fails to mention and that's how to fill in the dialog that pops up once the Toolkit has been installed and Eclipse has been restarted. I fill in the dialog as follows (with Notes 8.5 installed in C:\Program Files\Notes 8):

• Lotus Notes 8
• C:\Program Files\Notes8\framework\rcp\eclipse
• jre6
• 1.5
• Display the first time a new workspace opens

I have been hard at work on version 2 of LotusScript.doc and I'm getting very close to a beta candidate. My main issue is that I keep adding features instead of finishing the core product as I now have a framework that is far more extensible than the version 1 code.

I'm currently finishing the framed HTML output that also shipped with version 1 and in that regard I have a question for LotusScript.doc users. Which parts of the HTML output do you actually use? In version 1 you could select to include the follow design element types and have output about these output to the documentation:

• Script libraries
• Agents
• Database script
• Forms
• Views
• Pages
• Shared actions

Which parts do you actually use? Is there a better way to do it? Any parts that should highlighted differently?

Please donate

Based on prior and recent recommendations I have set up a Paypal account to accept donations to finance the development of the free version of LotusScript.doc version 2. All donations will be very much appreciated and help me justify the time I put into this.

Dan Sickles sent me a couple of Scala links after I tweeted that I was playing with Scala over the holidays. Thank you for those. I put them here if others are interested.

• Ruminations of a Programmer
• Scala book
• Scala XML resource