[jsword-devel] Clean Installation Problems

[Joe Walker]

DM Smith wrote:

> I am looking at getting JSword to work well from a clean installation. 
> That is, Sword (C++) has not been installed (or it has been installed 
> to a non-default location) and JSword is installed "for the first 
> time". To simulate this, I delete all traces of modules and ~/.jsword 
> then run it either in Eclipse or via webstart (a local, hand edited 
> jnlp file).

Is it possible to use a jnlp file to launch jsword in place of a 
.bat/.sh file?

> The problem I have encountered is multi-faceted, but it seems to 
> manifest itself in three ways.
> 1) JSword assumes that at least one bible is installed. If one is not 
> installed then the application does not work gracefully. Specifically 
> I get all kinds of un-helpful error messages, with Null Pointer 
> Exceptions and Book Exceptions. (I have a listing of where these 
> errors occurred, if anyone wants them, but for the sake of brevity in 
> this message, I left them out.)

I'd be interested in these. I won't be able to spend any serious time on 
it for another week or so until the study weekend is done, but God 
willing I'll have more time after then.

> 2) JSword assumes that Sword is installed. It checks for modules 
> installed in the Sword Module directory in one and only one place. If 
> the program is not installed there then JSword defaults to putting 
> modules in the root of the current drive. For me this is d:\modules 
> and d:\mods.d. On unix, I would guess that it would fail on superuser 
> permission problems. However, it does not look there to see if modules 
> are installed.

JSword does attempt to read Sword installed modules, although it clearly 
that doesn't work properly if it doesn't find Sword.
The following is supposed to happen:
The installer calls: SwordBookDriver.setSwordPath() as a result of the 
entry on line 50 of jsword/resource/config.xml.
If no sword paths are set then tries to guess using 
SwordBookDriver.getDefaultPaths() which just tries some obvious places - 
this fails for you because it doesn't try the D: drive.
What *should* happen I guess is that there is a default if all else 
fails to use $HOME/.jsword

> 3) JSword uses resource/version/ser directory to look for installed 
> bibles using the Ser driver. However, when it serializes them it puts 
> them in ~/.jsword/sword-[INITIALS]. The problem with looking at 
> resource/version/ser is that in a webstart setting this is inside 
> resource.jar. The driver does correctly use the ref.data and ref.index 
> on a subsequent run.

I've split search index storage from text storage. The stuff that gets 
written to ~/.jsword/ is in part the search index. I think the ser 
engine mistakenly creates the search indexes before it needs to, hence 
all the extra files that are created.
The Lucene search engine *I think* does a similar thing - it also needs 
to store its index somewhere.

The Ser search-engine is not part of the Ser book driver. They have the 
same name simply because the were once the same thing when searching was 
part of the responsibilities of a Book, and I suppose because they both 
work using serialization.

I would be happy to ignore the ser driver for use in webstart - it is 
very quick, but we don't have problems with speed with the Sword 
drivers, and in addition I think there could be some redistribution 
problems with the KJV Bible data in ser format because it could be 
derrived from On-Line Bible data. It does not contain strongs numbers 
which was the issue if I recall properly, however the Sword KJV is 
better so there isn't much benefit in the Ser version.

> The net effect of the last two problems is that restarting the 
> application after downloading/installing bibles, they don't show up as 
> having been installed. I have not looked at the Lucene driver to see 
> if it has similar assumptions.

There is another config entry "Sword.Download Directory" on line 54 of 
config.xml (defaults to something in .sword) where the directory used 
for download *should* also be included in the Path for "Sword.Module 
Search Path" (line 49). If not then Sword will not currently see 
downloaded modules.
I guess we should make ~/.jsword part of the default module search path 
*and* hack the SwordBookDriver to include the download directory in the 
module search path in some way.
The issue could be in having the Sword driver refreshing it's list of 
Bibles all the time. I guess it could cache the Books that it has 
registered against the source directory, and only update BookManager 
when there really is a change.

> I would like to know what the consensus on fixing these problems is.
>
> I would suggest that on first run (every run??) that it verifies the 
> run-time environment for its assumptions and if it assumed correctly, 
> then the program continues as it has. If it has not then it supplies a 
> coherent set of defaults and perhaps presents the user with a "Wizard" 
> to modify them.

Sounds good to me.
The config system was designed with Wizards in mind, but the wizard 
interface was never finished. It shouldn't take too much hacking to get 
it into shape. If that was done then we could add a new wizard simply by 
using a custom version of config.xml.

> Should the "ser" files be stored on a per user basis (i.e. in 
> ~/.jsword/...) or in a common area?

Good question.
For unix installs we probably need to have per-user at least an option. 
I don't know if there is even a sensible common area under webstart.
For a more normal windows application install, a common area makes more 
sense though.

> At this point should there be any concurrency concerns? Or do we 
> assume that modules and ser files may be shared but not networked 
> (that is the file system is on drives on the local machine)?

We are probably OK for most things, but I would expect search indexes to 
fail under some circumstances if they were shared (which currently they 
are not).

Joe.