[jsword-devel] JNLP and stuff

[Mark Goodwin]

> I think the principles are: 1. everyone ought to be able to build and 
> test, 2. Much as I think forks are a bad idea, if a fork happens then 
> they should have their own name and own keystore and so it is legitimate 
> to keep tight reign on the real keystore.
> We could have some ant tasks that created a keystore from scratch for 
> testing and debug - I think I sused it out once before, I'm sure I can 
> find it again.
>

OK - how about we have ant create a keystore unless there is already one
there, and have the jar.sign task get values for alias, passwords, etc.
from properties as I suggested before.   That way, people can build and
test using their own keystores, and we still have the option of keeping
keystores generated with genuine certificates safe.


> I wonder if we should unroll all needed jars, and re-roll them into 
> jsword.jar. It would make things simple, and could make it easy for us 
> to use a jar compacting tool. IIRC IBM have a fancy thing that examines 
> a jar file and rips out all of the unused classes and even methods! Not 
> sure if this works well though.
> OTOH it would make upgrade downloads bigger because it's an all or nothing.

I have to confess I don't like that idea much - as you say it's all or
nothing (I've tried the IBM tool, and it's OK).  How about we just
figure out a way of getting ant to sign every jar in
${target.deploy}/lib ?  That way people don't have to faff with signing
their own JARs with the keys ant has just generated for them.  I'll look
at this later today.

> >3) The NetUtil.getURLAsFile(URL) method can't use a
> >Resouce.getTempworkingDir() style method - Resource belongs to jsword
> >package, NetUtil is in common.  At present I've implemented getURLAsFile
> >using File.CreateTempFile so it uses the system temp folder -  this
> >willl do for the time being, but perhaps we should provide a project
> >agnostic interface under $blah.jsword.common for obtaining commonly
> >neaded things (like tempWorkingDirs, property files) which is
> >implemented by $blah.jsword.Resource?  Just a thought.
> >  
> >
> Um, yes. I guess I'd add: NetUtil.[g|s]etURLCacheDir(File) and have 
> config set this before we make any calls to getURLAsFile(URL)

That would work.

I've been thinking about the versions loading stuff this morning.  It
occurs to me that deploying versions in signed JARs with the rest of the
JNLP distribution is possibly not the best way of getting the Bible data
to the user across a network / the internet (although I'll continue on
this tack so we've got something for non-technical testers to work
with).  

I was thinking it might be good to have a 'version manager' of some
sort.  This might get the URL of a descriptor which tells it what bible
versions are available, what driver each version uses, and where the
data for each version can be obtained.  e.g.

<booklist provider="http://www.crosswire.org">
  <book type="bible">
    <version name="AV" description="the King James Authorised Version">
      <variant driver="ser" url="http://foo.com/avser.zip"/>
    </version>
    <version name="NIV" description="the New International Version">
      <variant driver="raw" url="http://bar.com/nivraw.zip"/>
    </version>
  </book>
  <book type="lexicon">
    <!-- you get the idea-->
  </book>
</booklist>

The version manager, given this information would be able to present
both NIV and AV as candidates for installation.  If either were to be
installed, the manager could download a copy of the selected version
from the specified URL and give the data to the relevant driver install
it.

The advantage of this is that it would work for any installation medium
- You could have a disk with one of these descriptors that tells jsword
what versions are on the disk, you could then just point the version
manager at the disk, and the rest would be automatic - no manual faffing
with versions dirs.

Just a thought.

What do you people think?