Good news for Mac Yosemite users out there (and possibly Mac Maverick users too): the current Greenstone 3.07 release-candidate binaries now include a JRE with the Mac Mountain Lion binary. This allows the Greenstone 3.07-rc2 Mountain Lion installer to now run out of the box on Mac Yosemite machines. You may still need to change the security settings on your Mac to allow you to open dmg binary files not created by Apple, as this is a new security feature on Macs, but otherwise the Greenstone installer and the Greenstone applications once installed should run fine on Yosemite too.

We’ve decided to come out with another intermediate release candidate, because the major change we’ve made are specific to a Mac binary this time. That means there is still time for Greenstone users to find and report on bugs, and for translators to add further translations and send these back in to us for inclusion in the upcoming official 3.07 release. Therefore, please do try out the current 3.07 rc2 release by heading on over to the Snapshots page, and let us know how the binaries fare, so we can improve them for the official release.

The GS3.07 release candidate 1 (3.07 rc1) was released on 03 Aug 2015 and can be downloaded from the snapshots page. There have been quite a few changes and improvements. These have been documented in the release notes.

The 3.07 rc1 binaries available are for Windows, Linux (32 and 64 bit) and Mac (Snow) Leopard and (Mountain) Lion. The Mountain Lion release can be used with some modification on Mac Maverick and Yosemite machines.

We’re still working on the final, official release of 3.07. It will include a Java Runtime Environment with the Mac Lion release so that this can be run on later releases of the Mac OS that do not include Java like Yosemite, without Greenstone Mac users having to download Java. In all we’d like to make the experience for Mac Maverick and Yosemite users much smoother than it’s been so far.

In the meantime, we would like to continue to encourage Greenstone users to try out the current 3.07 rc1 release and report back their experiences, in particular any bugs or issues they detected.

For those who want to compile 3.06 up from source, there is the 3.06 “source distribution” package.
Those who have installed the binary and who eventually want to recompile can top up their binary installation with the 3.06 “source component”.

You can get the binary for your operating system from the Greenstone 3 home page’s Download section at

These contain instructions on how to install the binaries, or compile with the source distribution or source component for your operating system, as well as information on the basic of use Greenstone and its new features. The release notes may get modified and expanded over time, as questions appear.

For those who want to follow along with the Greenstone 3 tutorials, these are at

It explains the use of the new Format Conversion Wizard that’s now part of Greenstone 3.06’s GLI and which automates some of the conversion process, while allowing you to interactively modify its suggested Greenstone 3 format statements. Therefore, copy a Greenstone 2 collection into your Greenstone 3.06 installation’s web/sites/localsite/collect/ folder, open it in 3.06 GLI and try out the Format Conversion Wizard.

If you discover bugs or encounter any issues, join the mailing list at greenstone-users @ list.waikato.ac.nz and drop us a message, and we’ll try to get it fixed.

As several people had encountered issues in the recent 2.85 release, a lot of this week was spent looking at them so that we can get 2.86 out as soon as possible.

The bugs and oversights are not fatal and work-arounds are possible:

1) If you don’t have the PDF-box extension for Greenstone installed already, GLI will suggest where it can be obtained from. However, the URL it provides points to an olderversion of the PDF-box extension, which happens to be one that’s not functional. If you want the version of PDF-Box that works with 2.85, get it from

or http://trac.greenstone.org/browser/main/tags/2.85/gs2-extensions/pdf-box/trunk/pdf-box-java.zip

2) The Greenstone demo collection in 2.85 contains HTML files that can’t get converted into XML properly enough to work well with the flash file generated by the Realistic Book feature. So if you’re thinking of testing out the realistic book option of the HTMLPlugin against the HTML files included in the Greenstone demo collection, rather than against your own HTML files, get the improved demo collection from SVN at http://svn.greenstone.org/main/trunk/greenstone2/collect/demo

3) On Vista, if your Greenstone is installed in a path containing brackets, such as “Program Files (x86)” as can happen on Windows 7 machines, then launching Greenstone is likely to fail. On Windows, spaces in Greenstone’s installation path are okay, but brackets aren’t handled well-enough yet. This will be fixed in a future release of Greenstone 2.

4) The fourth bug is more serious in that there is no work-around. It was found by a member on the mailing list when he was using the Datelist Classifier and discovered that references to [ex.srclink] or [srclink] in his Format statements did not get resolved to the URL of the source file. (However, the default browsing classifiers had no problem with such Format statements and would display the correct URL.) This has now been fixed by Dr Bainbridge and will be present in the next release of Greenstone.

5) Another discovery made is that Ubuntu now seems to have a problem with the open-office extension. This was not the case some two months back when, after a bugfix, the extension was tested on the Ubuntu both here and by another dedicated member of the Greenstone family on his own Ubuntu. However, the new problem has been confirmed to now exist, including when run from the commandline, and even older versions of the Greenstone extension are performing similarly despite having worked at one point. Perhaps this has something to do with updates on the Ubuntu, but we’ll be investigating it further.

At last, we did it. After a lot of testing, bug discovery and fixing, we’ve finally released Greenstone 2.85. It should be much improved from 2.84. There were also some last minute changes from release candidate version 2.

There was a lot of testing going on in the last 2 months, and I forgot all about writing blog entries.

The first stage of testing was to go through the Greenstone tutorials on Windows (Vista), Linux (Ubuntu) and Mac (Leopard). Some bugs were discovered and fixed, and after that RC1 of GS2.85 could be released.

Thereafter, further tests were conducted on all three OS: testing out combinations of the 3 indexers and 3 database types, processing of a range of file types including the use of Greenstone’s PDFBox and OpenOffice extensions, filenames with different encodings and HTML files that interlink with each other using different encodings, the remote Greenstone server and the GLI applet were tested out, as well as spaces in the filepath for Windows. This time, the tests were conducted on Windows XP, Linux CentOS as well as Mac Leopard again. A lot of bugs had still got through the net after the first stage of testing, but were caught this time around and fixed for the release of GS2.85 RC2.

Greenstone 2.85 RC2 was finally released on Wednesday 26 October 2011. The Greenstone Team invites all those interested to please test the new release binaries out, which can be obtained from http://www.greenstone.org/snapshots, and write back on any bugs or issues encountered. The updated release notes are at http://wiki.greenstone.org/wiki/index.php/2.85_Release_Notes

The release notes already contain instructions on a patch for a minor issue that Diego discovered in the earlier release and which had persisted into the current one.

It’s been about 4 weeks since I wrote an entry. In the meantime we’ve been tidying up the last of the To Do list items for the upcoming GS2 release and several of the To Do list items for the GS3 release. Sam is now hard working on the GS3 interface alongside his other work on the Document Maker. It now looks like GS3 may be released separately, after GS2.

Some of the more involved things that required doing were:

testing OAI (dc.Resource Identifier issues) and downloading over OAI

The extracted embedded metadata, ex.*.metadata (e.g. ex.dc.* prefixes), needed to be handled different from ex.metadata. This required some changes in various files and a lot of testing.

Conflicts between EmbeddedMetadataPlugin and some of the existing Plugins in the pipeline (OAI, DSpace, PDF plugins). Fortunately, Dr Bainbridge came up with fixes. After some testing, the known problems with these plugins no longer exist. With the tutorials we will continue to investigate how well other plugins interact with the EmbeddedMetaPlugin.

The OAI validator at openarchives now had a test where GS2’s OAI server failed and a different one where the GS3 OAI server failed. These have been fixed up.

The GS3 installer needed to have an admin page, like the GS2 installer does, where the user can enable admin pages and provide a password.

wvware.pl is a new intermediary script to launch wvware in its own particular environment. This script is necessary in order for wvware’s required environment not to be set globally (thereby tampering with Linux’ windowing/GUI libraries)

At the moment, after John Rose’s request, we’re in the process of merging the two server configuration files (glisite.cfg and llssite.cfg), so we can have just one, with some properties qualified by a “gli” prefix. The Server.jar code, the GS2 C++ code, the startup scripts and config files have been sufficiently modified to work with the work-in-progress on the GLI code, while still working with the stable GLI. Changing the GLI code was tricky two years ago, and made the code’s behaviour rather complex. Now that I’m in the process of testing the latest overhaul to it, the changes I’ve just made to what was stable are still very buggy and reproducing the bugs takes some time. Fortunately, without the changes to the GLI code, everything else committed is able to work as accurately as before, which is fortunate since if I break anything, it will be just the LocalLibraryServer.java GLI code that once committed needs to be reverted.

The above task has now been completely resolved, and changes committed after being tested thoroughly on both Windows and Linux.

Minor issues also kept popping up over the last month.

There was a Z3950 “issue”that sidetracked me and which turned out not to be an issue after all: The Library of Congress’ Z3950 address seems to return SRU data. The fix is simply for the user to use the right module of the download pane.

A bug in starting and stopping GS3 via GLI on windows

One Greenstone member encountered a unicode issue that I wasn’t able to reproduce after initial investigations.

Minor but frustrating bugs with the GLI for GS3 have been resolved (an extra nested <format/> tag appearing when all format statements have been removed, and the preview button activating itself when editing format statements in an unbuilt GS3 collection)

Fixed GS3’s way of handling the port in the GSI application, so that it is no longer arbitrarily modified. The Do Not Modify port is still available.

Some requests on the mailing list like porting indexed databases from one GS2 version to the next, since changes had been made to the name of an ex.metadata