<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
A patch for JSword is attached. The Verse class was not maintaining<br>
its own versification value and so it was impossible for Verse to<br>
operate properly in some circumstances. This ultimately led to<br>
unhandled exceptions when reading certain passages from non-default<br>
versified Bibles such as IBT's UZV module, Ps 117:1-29 with Bible<br>
Desktop.<br>
<br>
The crux of the problem is seen in:<br>
org.crosswire.jsword.passage.
<div id=":ti"><wbr>Passage.getPassage(Key),<br>
where Passage maintains its own versification value, but (Verse)
Key<br>
did not. So it was impossible to insure correct construction of a<br>
Passage from an arbitrary Verse Key (all Passages returned were
being<br>
KJV versified even if the Verse was not KJV). This led to
incorrect<br>
Passage assignments and unhandled exceptions (such as when viewing<br>
IBT's UZV module Ps 117:1-29).<br>
<br>
The solution is pretty easy- require a Versification when<br>
instantiating any Verse class, and then retain that value within
the<br>
Verse key. A method was added called Verse.getVersification().
Also,<br>
to fix the above mentioned bug, Passage.getPassage(Key) now casts
the<br>
Key as Verse, and if successful, it reads the Verse's
Versification to<br>
pass it along to PassageKeyFactory.getKey(), thus enabling the<br>
resulting Passage to have the correct Versification and value.<br>
<br>
This fix is also logically necessary since Verse points to an
actual<br>
Bible verse, and the versification is a necessary part of any
actual<br>
Bible address location.<br>
<br>
I tested this patch with common-junit-alltests and everything
passed<br>
expect 4 failures related to Lucene stemming and stop-words. These<br>
seem to be related to the Lucene version and appear totally
unrelated<br>
related to Verse Key. I also tested a bit with Bible-Desktop.<br>
<br>
John<br>
</div>
</body>
</html>