Re: [greenstone-users] Some doubts About Gatherer

From John M Thompson
DateMon, 18 Aug 2003 11:13:23 +1200
Subject Re: [greenstone-users] Some doubts About Gatherer
In-Reply-To (3F3D7C64-E8DFCA8B-siu-edu-ar)
Hello Emiliano,

I'll try to answer your questions, but we might need a bit more
information for a few of them:

Emiliano Marmonti wrote:

>Hello all
>I have a doubt about Gatherer. I've tried to use Gatherer that comes
>with Win'32 GSDL 2.40 distribution, but when it installs, aborts saying
>that the Greenstone version is too old for continue (?).
1. Gatherer needs a newer version of Greenstone (2.40+) to run properly
and so checks on install whether one is available. Did you install
Greenstone 2.40 at the same time as the Gatherer?

>John, I've downloaded from CVS and could make it work, but when it
>starts appears a message saying that could not find the Greenstone
>I have tried to touch gli.bat
>inserting the path or inserting the path in the input proxy box (knowing
>that will not work) to the local gsdl but don't works.
2. The Gatherer downloaded from CVS now assumes it will be installed in
the greenstone file hierarchy - in other words it defaults to living in
<greenstone_install>/gli/. If you install it somewhere else you need to
edit the gli.bat file to tell it the path to your greenstone
installation. When editing the batch file look for a section that starts
":findGSDL" (line 18). Underneath is a command "set GSDLPATH=". Supply
the full path to your gsdl install such as "set
GSDLPATH=F:applicationsgsdl" or whatever. This may also help for
question 4 below.

>The exactly message is that: "could not view new
>Collections unless specify the path to the Greenstone distribution". It
>proposes to insert this data in an input box below (?) or entering in
>preferences/Connection Tab. In this tab I could define a proxy, but I'm
>not using any proxy, I have gsdl and gli installed in the same Win 32
>machine under an Apache web-server.
3. The Gatherer cannot automatically detect any webserver other than the
local library that comes with Windows version of GSDL. In theory, since
your installing under windows, it should have found the one located in
your greenstone install (assuming it knew how to get there). Since it
didn't it has prompted you to fill in the path to your local webserver.
Unfortunately this prompt is pretty cryptic (and selective) about what
to enter. In order to specify a path it must begin with the protocol
"http://" and end with the cgi executable name "library", so my machine
is "" and perhaps
your machines path might be "http://localhost:8080/gsdl/library". Also
note that if greenstones local library server (server.exe) wasn't
detected automatically then there is no way for the Gatherer to start
it. Thus you would have to ensure greenstone is started before you run
gli, and enter the address greenstone is running on (which can be found
by looking in the address used by the internet browser that opens up
when you "Enter Library"). This should be something like

>Another thing I'm trying to test is related to use Gatherer for a
>Linux-gsdl collection. I mean, using Gatherer from Windows connected
>through a Samba to a Linux. Perhaps the above answer could be usefull
>for this purpose. I need to tell Gatherer where to find gsdl... And
>testing if could work if gsdl resides in a network drive.
4. Hopefully 2 above explains how to specify the path to your
installation. However cross-platform running of GLI was never
envisioned, and so there is a further problem. In order to make
Greenstone run a certain file must be run first, setup.bat under
windows, under linux, and so the first thing gli.bat does is
search for the setup.bat file using the GSDLPATH as supplied or
automatically determined. However if your greenstone install was for
linux, then there will be no setup.bat. Maybe Samba will allow you to
run a bash script from a batch file, and handle conversion (from linux
to windows) of the enviroment settings made in the script. You may also
be able to copy across the setup.bat file from a windows install to your
linux install, and that would be enough. It all depends how Samba
handles environment settings - but no-one here knows anything about Samba.

>Another thing to question is about hierachical clasiffiers. I want to
>know if is there a way to build the .txt file automatically. I mean if
>Gatherer could generate this .txt file dinamically using the Dictionary,
>or other procedure.
5. GLI automatically builds the txt files. All you do is enter
hierarchical metadata values, and GLI handles the rest. Please refer to
GLIs online documentation as to how to specify hierarchy values.

>And a last question: Is there an external file in
>Gatherer that could be used for translation purposes or must touch the
>.java files?
6. If you mean you want to translate the string fragments shown within
the Gatherer (such as the labels on buttons, and the text in the menus),
then you can easily create a new dictionary. First of all you need to
get a copy of the file. If your using the CVS
version of GLI, then it can be found in the classes folder of the gli
install. If you are using other versions it might be in the same place,
or you may need to extract it from the gli.jar (using jar or some
unzipping program). The dictionary is loaded using the java
ResourceBundle class (see
java.util.Locale, java.lang.ClassLoader)" ) and so you rename the
dictionary file based upon your locale, so if you were developing a
french dictionary in France you would use the name Ensure this file is in the classes folder.
Next edit the file - each line of the file is either a comment (starts
with "#") or a key:value pair used in the GLI GUI. Leave the key in
place, and change each value as necessary. The "{0}" are arguments that
will be filled in by GLI - there are plans to make them less cryptic
along the lines of {filename_0}, but at the moment you'll just have to
guess what they are from their context. Once the dictionary is complete,
edit the config.xml file found in your GLI folder and change the value
of "general.locale" to the appropriate one (or better still check if
java is using the correct default locale - if you know how). Next time
you start GLI it should use your new dictionary.

Good Luck,
John Thompson