[jsword-devel] A few more changes in SVN

[DM Smith]

I pulled com.ice.tar into its own project, javatar. The build there will 
install into jar/javatar-2.5/javatar-2.5.jar. If you recall the only 
reason that we don't use the distribution as-is, is that WebStart does 
not like its manifest. By putting it in its own project, the following 
is accomplished:
1) It is out of the way and  a bit more protected from change.
2) The nightly webstart is slightly faster as it is not brought down all 
the time.
3) The build is slightly faster as it is not rebuilt.
4) The QA tools (checkstyle, findbugs, ....) don't look at it any more.
5) Problems in it are not reported by Eclipse.

I also created jsword-limbo (I thought about naming it jsword-bitbucket) 
and moved all limbo and historical code along with test code, into it. 
This accomplishes:
1) Simplifies the build. Lots of rules were present to keep the limbo 
code out of the production jars and out of the zips and tars.
2) Reduces the size of the projects.
3) Uncovered some trivial limbo code in production. (e.g. a Msg package 
had some messages for limbo code)

I kept biblemapper as its own project. And I tried to eliminate any 
dependence upon limbo. I moved two packages from limbo into it as they 
were only being used by bible mapper and not by any other code. The 
upshot is that one class still depends upon limbo code. In one instance, 
it uses the old search, which needs to be updated, in the other case, I 
did not bother trying to figure out, but it looks simple enough to fix. 
Bottom line, the Bible Mapper is not too far from being ready for 
incorporation.

I also spent a little time on "historical" This is stuff that we have 
not tried to keep in sync. I was curious how far out of date it was. It 
depends on bsf and mozilla, which I did not bring in. But I fixed the 
obvious problems (e.g. package spec not matching the path, class name 
not matching the file name, simple method signature problems). There is 
some interesting stuff in here related to allowing a user to write 
scripts against the api.

So with all these changes and the ones I did the other day:
1) Each project serves a single purpose and this is reflected in the 
code that is present. (This may not be true of BibleDesktop whose 
purpose is to provide a GUI and to provide an executable. But until the 
creation of an executable becomes more complicated, it does not make 
sense to split it out.)
2) Each project is structured just like the others.