From dmsmith at crosswire.org  Tue Mar  1 06:57:49 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Tue, 1 Mar 2011 08:57:49 -0500
Subject: [jsword-devel] Error with Strongs tags in Russian RST bible
In-Reply-To: <6A12B600-6195-4698-A7CD-572C42474411@crosswire.org>
References: <AANLkTimyWhGYSryauoU8uO57Wa8G8qrd34wH1w4m3VEY@mail.gmail.com>
 <6A12B600-6195-4698-A7CD-572C42474411@crosswire.org>
Message-ID: <F964BE86-2953-4523-9906-4868E4011567@crosswire.org>

Martin,
Thanks for the report. I've just checked in a fix for this bug: JS-166. The changed file is o.c.j.book.filter.gbf.GBFTags.java. Can you verify that it fixes your problem.
In Him,
	DM

On Feb 28, 2011, at 9:20 PM, DM Smith wrote:

> The problem seems to be the following:
> RST produces:
> <div>
> 	<title type='x-gen'>
> 		Colossians 1:1
> 	</title>
> 	<verse osisID='Col.1.1'>
> 		<w lemma='strong:3972'>
> 			?????
> 		</w>
> 		, 
> 		<w lemma='strong:1223|strong:2307'>
> 			?????
> 		</w>
> 		 
> 		<w lemma='strong:2316'>
> 			??????
> 		</w>
> 		 
> 		<w lemma='strong:652'>
> 			???????
> 		</w>
> 		 
> 		<w lemma='strong:2424'>
> 			??????
> 		</w>
> 		 
> 		<w lemma='strong:5547'>
> 			??????
> 		</w>
> 		, 
> 		<w lemma='strong:2532'>
> 			?
> 		</w>
> 		 
> 		<w lemma='strong:5095'>
> 			???????
> 		</w>
> 		<w lemma='strong:80'>
> 			????
> 		</w>
> 		,
> 	</verse>
> </div>
> KVJ produces:
> <div>
> 	<title type='x-gen'>
> 		Colossians 1:1
> 	</title>
> 	<verse osisID='Col.1.1'>
> 		<w lemma='strong:G3972' morph='robinson:N-NSM' src='1'>
> 			Paul
> 		</w>
> 		, 
> 		<w lemma='strong:G652' morph='robinson:N-NSM' src='2'>
> 			an apostle
> 		</w>
> 		 
> 		<w lemma='strong:G2424' morph='robinson:N-GSM' src='3'>
> 			of Jesus
> 		</w>
> 		 
> 		<w lemma='strong:G5547' morph='robinson:N-GSM' src='4'>
> 			Christ
> 		</w>
> 		 
> 		<w lemma='strong:G1223' morph='robinson:PREP' src='5'>
> 			by
> 		</w>
> 		 
> 		<w lemma='strong:G2307' morph='robinson:N-GSN' src='6'>
> 			the will
> 		</w>
> 		 
> 		<w lemma='strong:G2316' morph='robinson:N-GSM' src='7'>
> 			of God
> 		</w>
> 		, 
> 		<w lemma='strong:G2532' morph='robinson:CONJ' src='8'>
> 			and
> 		</w>
> 		 
> 		<w lemma='strong:G5095' morph='robinson:N-NSM' src='9'>
> 			Timotheus
> 		</w>
> 		 
> 		<transChange type='added'>
> 			our
> 		</transChange>
> 		 
> 		<w lemma='strong:G3588 strong:G80' morph='robinson:T-NSM robinson:N-NSM' src='10 11'>
> 			brother
> 		</w>
> 		,
> 	</verse>
> </div>
> 
> There are 2 significant differences in the RST:
> First is does not prefix the various Strong's Numbers with G or H. Second it separates two numbers in a row with '|' rather than ' '.
> 
> The first problem has to be fixed in ..../GBFilter.java as there is no way of telling whether a value is Greek (G) or Hebrew (H) otherwise. The numbers overlap. The second can be fixed in either simple.xsl (or whatever you are using), or in GBF Filter. Since OSIS specifies a space, GBFFilter should be changed. Also, it fixes it once for all frontends.
> 
> 
> In Him,
> 	DM
> 
> On Feb 28, 2011, at 4:03 PM, Martin Denham wrote:
> 
>> And Bible throws an error when attempting to parse the xml from the Russian RST module.  It appears to me that the Strongs tags do not conform to the correct xml format.  
>> 
>> I printed out the OSIS xml for the beginning of Colossians and got (ignore the question marks which are just Russian characters):
>> <verse osisID='Col.1.1'/>?????<WG3972>, ?????<WG1223><WG2307> ??????<WG2316>...
>> 
>> which isn't valid xml because the Strongs tags are all unmatched opening tags, despite not being valid OSIS tags, but then the RST is originally in GBF format and not OSIS.
>> 
>> When I select RST in BibleDesktop and turn on Strongs Numbers it displays the numbers but they are not shown as Strongs links but large red tags.
>> 
>> Any idea what might be the problem here - I thought it could possibly be an error in the module or in JSword GBF conversion to OSIS?
>> 
>> This error also affects the RusVZh module.  Both modules are GBF format.
>> 
>> Thanks
>> Martin
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel



From chris at burrell.me.uk  Tue Mar  1 13:52:28 2011
From: chris at burrell.me.uk (Chris Burrell)
Date: Tue, 1 Mar 2011 20:52:28 +0000
Subject: [jsword-devel] NASB on crosswire
Message-ID: <AANLkTi=cJaj=G+Tzr_gknZjFeAu8x7dOpw-tFUDfRqYW@mail.gmail.com>

Hi

I see that the NASBnew is available on the crosswire site. But not available
for download and use say on STEP/Bible Desktop?

Any particular reason for that? Or am i missing a repository somewhere?

Cheers
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110301/1d372a0d/attachment.html>

From yighu at yahoo.com  Wed Mar  2 11:38:51 2011
From: yighu at yahoo.com (Yiguang Hu)
Date: Wed, 2 Mar 2011 10:38:51 -0800 (PST)
Subject: [jsword-devel] JSword on GAE?
Message-ID: <974704.11139.qm@web36106.mail.mud.yahoo.com>


I am interested in put my gsword onto GAE. How much affort it takes to change jsword to work with GAE if we use this 
http://code.google.com/p/gaelucene/

or if there are other alternate?

Thanks
Yiguang




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110302/ca37a7a6/attachment.html>

From mjdenham at gmail.com  Wed Mar  2 14:18:33 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Wed, 2 Mar 2011 21:18:33 +0000
Subject: [jsword-devel] Error with Strongs tags in Russian RST bible
In-Reply-To: <F964BE86-2953-4523-9906-4868E4011567@crosswire.org>
References: <AANLkTimyWhGYSryauoU8uO57Wa8G8qrd34wH1w4m3VEY@mail.gmail.com>
 <6A12B600-6195-4698-A7CD-572C42474411@crosswire.org>
 <F964BE86-2953-4523-9906-4868E4011567@crosswire.org>
Message-ID: <AANLkTinN8fbPF34UwOAY8A5UgSBSFnf0nnzKZzgWe0Dm@mail.gmail.com>

Thanks for the quick fix.  Strong's Number links in the RST work great now.


I discovered an And Bible bug too in the same area affecting non-OSIS format
modules which confused me for a while but now everything is fine.

Martin

On 1 March 2011 13:57, DM Smith <dmsmith at crosswire.org> wrote:

> Martin,
> Thanks for the report. I've just checked in a fix for this bug: JS-166. The
> changed file is o.c.j.book.filter.gbf.GBFTags.java. Can you verify that it
> fixes your problem.
> In Him,
>         DM
>
> On Feb 28, 2011, at 9:20 PM, DM Smith wrote:
>
> > The problem seems to be the following:
> > RST produces:
> > <div>
> >       <title type='x-gen'>
> >               Colossians 1:1
> >       </title>
> >       <verse osisID='Col.1.1'>
> >               <w lemma='strong:3972'>
> >                       ?????
> >               </w>
> >               ,
> >               <w lemma='strong:1223|strong:2307'>
> >                       ?????
> >               </w>
> >
> >               <w lemma='strong:2316'>
> >                       ??????
> >               </w>
> >
> >               <w lemma='strong:652'>
> >                       ???????
> >               </w>
> >
> >               <w lemma='strong:2424'>
> >                       ??????
> >               </w>
> >
> >               <w lemma='strong:5547'>
> >                       ??????
> >               </w>
> >               ,
> >               <w lemma='strong:2532'>
> >                       ?
> >               </w>
> >
> >               <w lemma='strong:5095'>
> >                       ???????
> >               </w>
> >               <w lemma='strong:80'>
> >                       ????
> >               </w>
> >               ,
> >       </verse>
> > </div>
> > KVJ produces:
> > <div>
> >       <title type='x-gen'>
> >               Colossians 1:1
> >       </title>
> >       <verse osisID='Col.1.1'>
> >               <w lemma='strong:G3972' morph='robinson:N-NSM' src='1'>
> >                       Paul
> >               </w>
> >               ,
> >               <w lemma='strong:G652' morph='robinson:N-NSM' src='2'>
> >                       an apostle
> >               </w>
> >
> >               <w lemma='strong:G2424' morph='robinson:N-GSM' src='3'>
> >                       of Jesus
> >               </w>
> >
> >               <w lemma='strong:G5547' morph='robinson:N-GSM' src='4'>
> >                       Christ
> >               </w>
> >
> >               <w lemma='strong:G1223' morph='robinson:PREP' src='5'>
> >                       by
> >               </w>
> >
> >               <w lemma='strong:G2307' morph='robinson:N-GSN' src='6'>
> >                       the will
> >               </w>
> >
> >               <w lemma='strong:G2316' morph='robinson:N-GSM' src='7'>
> >                       of God
> >               </w>
> >               ,
> >               <w lemma='strong:G2532' morph='robinson:CONJ' src='8'>
> >                       and
> >               </w>
> >
> >               <w lemma='strong:G5095' morph='robinson:N-NSM' src='9'>
> >                       Timotheus
> >               </w>
> >
> >               <transChange type='added'>
> >                       our
> >               </transChange>
> >
> >               <w lemma='strong:G3588 strong:G80' morph='robinson:T-NSM
> robinson:N-NSM' src='10 11'>
> >                       brother
> >               </w>
> >               ,
> >       </verse>
> > </div>
> >
> > There are 2 significant differences in the RST:
> > First is does not prefix the various Strong's Numbers with G or H. Second
> it separates two numbers in a row with '|' rather than ' '.
> >
> > The first problem has to be fixed in ..../GBFilter.java as there is no
> way of telling whether a value is Greek (G) or Hebrew (H) otherwise. The
> numbers overlap. The second can be fixed in either simple.xsl (or whatever
> you are using), or in GBF Filter. Since OSIS specifies a space, GBFFilter
> should be changed. Also, it fixes it once for all frontends.
> >
> >
> > In Him,
> >       DM
> >
> > On Feb 28, 2011, at 4:03 PM, Martin Denham wrote:
> >
> >> And Bible throws an error when attempting to parse the xml from the
> Russian RST module.  It appears to me that the Strongs tags do not conform
> to the correct xml format.
> >>
> >> I printed out the OSIS xml for the beginning of Colossians and got
> (ignore the question marks which are just Russian characters):
> >> <verse osisID='Col.1.1'/>?????<WG3972>, ?????<WG1223><WG2307>
> ??????<WG2316>...
> >>
> >> which isn't valid xml because the Strongs tags are all unmatched opening
> tags, despite not being valid OSIS tags, but then the RST is originally in
> GBF format and not OSIS.
> >>
> >> When I select RST in BibleDesktop and turn on Strongs Numbers it
> displays the numbers but they are not shown as Strongs links but large red
> tags.
> >>
> >> Any idea what might be the problem here - I thought it could possibly be
> an error in the module or in JSword GBF conversion to OSIS?
> >>
> >> This error also affects the RusVZh module.  Both modules are GBF format.
> >>
> >> Thanks
> >> Martin
> >> _______________________________________________
> >> jsword-devel mailing list
> >> jsword-devel at crosswire.org
> >> http://www.crosswire.org/mailman/listinfo/jsword-devel
> >
> >
> > _______________________________________________
> > jsword-devel mailing list
> > jsword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110302/7292a60d/attachment.html>

From mjdenham at gmail.com  Wed Mar  2 14:20:37 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Wed, 2 Mar 2011 21:20:37 +0000
Subject: [jsword-devel] Error with Strongs tags in Russian RST bible
In-Reply-To: <AANLkTinN8fbPF34UwOAY8A5UgSBSFnf0nnzKZzgWe0Dm@mail.gmail.com>
References: <AANLkTimyWhGYSryauoU8uO57Wa8G8qrd34wH1w4m3VEY@mail.gmail.com>
 <6A12B600-6195-4698-A7CD-572C42474411@crosswire.org>
 <F964BE86-2953-4523-9906-4868E4011567@crosswire.org>
 <AANLkTinN8fbPF34UwOAY8A5UgSBSFnf0nnzKZzgWe0Dm@mail.gmail.com>
Message-ID: <AANLkTimm6OAf45_gywo-a1yVPaUdU6Z+NB8pKVdSC8cd@mail.gmail.com>

It's strange that the JS-166 JIRA notification didn't come through via
e-mail like new JIRAs normally do.

On 2 March 2011 21:18, Martin Denham <mjdenham at gmail.com> wrote:

> Thanks for the quick fix.  Strong's Number links in the RST work great now.
>
>
> I discovered an And Bible bug too in the same area affecting non-OSIS
> format modules which confused me for a while but now everything is fine.
>
> Martin
>
> On 1 March 2011 13:57, DM Smith <dmsmith at crosswire.org> wrote:
>
>> Martin,
>> Thanks for the report. I've just checked in a fix for this bug: JS-166.
>> The changed file is o.c.j.book.filter.gbf.GBFTags.java. Can you verify that
>> it fixes your problem.
>> In Him,
>>         DM
>>
>> On Feb 28, 2011, at 9:20 PM, DM Smith wrote:
>>
>> > The problem seems to be the following:
>> > RST produces:
>> > <div>
>> >       <title type='x-gen'>
>> >               Colossians 1:1
>> >       </title>
>> >       <verse osisID='Col.1.1'>
>> >               <w lemma='strong:3972'>
>> >                       ?????
>> >               </w>
>> >               ,
>> >               <w lemma='strong:1223|strong:2307'>
>> >                       ?????
>> >               </w>
>> >
>> >               <w lemma='strong:2316'>
>> >                       ??????
>> >               </w>
>> >
>> >               <w lemma='strong:652'>
>> >                       ???????
>> >               </w>
>> >
>> >               <w lemma='strong:2424'>
>> >                       ??????
>> >               </w>
>> >
>> >               <w lemma='strong:5547'>
>> >                       ??????
>> >               </w>
>> >               ,
>> >               <w lemma='strong:2532'>
>> >                       ?
>> >               </w>
>> >
>> >               <w lemma='strong:5095'>
>> >                       ???????
>> >               </w>
>> >               <w lemma='strong:80'>
>> >                       ????
>> >               </w>
>> >               ,
>> >       </verse>
>> > </div>
>> > KVJ produces:
>> > <div>
>> >       <title type='x-gen'>
>> >               Colossians 1:1
>> >       </title>
>> >       <verse osisID='Col.1.1'>
>> >               <w lemma='strong:G3972' morph='robinson:N-NSM' src='1'>
>> >                       Paul
>> >               </w>
>> >               ,
>> >               <w lemma='strong:G652' morph='robinson:N-NSM' src='2'>
>> >                       an apostle
>> >               </w>
>> >
>> >               <w lemma='strong:G2424' morph='robinson:N-GSM' src='3'>
>> >                       of Jesus
>> >               </w>
>> >
>> >               <w lemma='strong:G5547' morph='robinson:N-GSM' src='4'>
>> >                       Christ
>> >               </w>
>> >
>> >               <w lemma='strong:G1223' morph='robinson:PREP' src='5'>
>> >                       by
>> >               </w>
>> >
>> >               <w lemma='strong:G2307' morph='robinson:N-GSN' src='6'>
>> >                       the will
>> >               </w>
>> >
>> >               <w lemma='strong:G2316' morph='robinson:N-GSM' src='7'>
>> >                       of God
>> >               </w>
>> >               ,
>> >               <w lemma='strong:G2532' morph='robinson:CONJ' src='8'>
>> >                       and
>> >               </w>
>> >
>> >               <w lemma='strong:G5095' morph='robinson:N-NSM' src='9'>
>> >                       Timotheus
>> >               </w>
>> >
>> >               <transChange type='added'>
>> >                       our
>> >               </transChange>
>> >
>> >               <w lemma='strong:G3588 strong:G80' morph='robinson:T-NSM
>> robinson:N-NSM' src='10 11'>
>> >                       brother
>> >               </w>
>> >               ,
>> >       </verse>
>> > </div>
>> >
>> > There are 2 significant differences in the RST:
>> > First is does not prefix the various Strong's Numbers with G or H.
>> Second it separates two numbers in a row with '|' rather than ' '.
>> >
>> > The first problem has to be fixed in ..../GBFilter.java as there is no
>> way of telling whether a value is Greek (G) or Hebrew (H) otherwise. The
>> numbers overlap. The second can be fixed in either simple.xsl (or whatever
>> you are using), or in GBF Filter. Since OSIS specifies a space, GBFFilter
>> should be changed. Also, it fixes it once for all frontends.
>> >
>> >
>> > In Him,
>> >       DM
>> >
>> > On Feb 28, 2011, at 4:03 PM, Martin Denham wrote:
>> >
>> >> And Bible throws an error when attempting to parse the xml from the
>> Russian RST module.  It appears to me that the Strongs tags do not conform
>> to the correct xml format.
>> >>
>> >> I printed out the OSIS xml for the beginning of Colossians and got
>> (ignore the question marks which are just Russian characters):
>> >> <verse osisID='Col.1.1'/>?????<WG3972>, ?????<WG1223><WG2307>
>> ??????<WG2316>...
>> >>
>> >> which isn't valid xml because the Strongs tags are all unmatched
>> opening tags, despite not being valid OSIS tags, but then the RST is
>> originally in GBF format and not OSIS.
>> >>
>> >> When I select RST in BibleDesktop and turn on Strongs Numbers it
>> displays the numbers but they are not shown as Strongs links but large red
>> tags.
>> >>
>> >> Any idea what might be the problem here - I thought it could possibly
>> be an error in the module or in JSword GBF conversion to OSIS?
>> >>
>> >> This error also affects the RusVZh module.  Both modules are GBF
>> format.
>> >>
>> >> Thanks
>> >> Martin
>> >> _______________________________________________
>> >> jsword-devel mailing list
>> >> jsword-devel at crosswire.org
>> >> http://www.crosswire.org/mailman/listinfo/jsword-devel
>> >
>> >
>> > _______________________________________________
>> > jsword-devel mailing list
>> > jsword-devel at crosswire.org
>> > http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110302/65bd7382/attachment-0001.html>

From jira at crosswire.org  Wed Mar  2 14:25:40 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Wed, 2 Mar 2011 14:25:40 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-166) GBF Strong's Number does
 not display properly
Message-ID: <979294857.6.1299101140993.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051#comment-14051 ] 

Martin Denham commented on JS-166:
----------------------------------

Strongs links now work in the RST on And Bible.

> GBF Strong's Number does not display properly
> ---------------------------------------------
>
>                 Key: JS-166
>                 URL: http://www.crosswire.org/bugs/browse/JS-166
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.gbf
>    Affects Versions: 1.6
>         Environment: All
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> The GBF filter produces Strong's numbers of the form <w lemma="strong:1234|strong:2345">...</w>
> This is wrong for 2 reasons:
> # It does not preserve the G or H, so the Strong's number is not properly identified
> # It separates multiple values with '|' not ' '
> The result is that simple.xsl of BibleDesktop displays it very badly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From mjdenham at gmail.com  Wed Mar  2 14:50:13 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Wed, 2 Mar 2011 21:50:13 +0000
Subject: [jsword-devel] Exception bubbling
In-Reply-To: <AANLkTinzs1=L3GgHRriEPOUG4MNdQY6nnjnV1sR8v54U@mail.gmail.com>
References: <AANLkTinzs1=L3GgHRriEPOUG4MNdQY6nnjnV1sR8v54U@mail.gmail.com>
Message-ID: <AANLkTimKQRF9T7yCi5uismtX9v=w-BtbrisBxdOeTACm@mail.gmail.com>

I tend to use RuntimeExceptions with web apps where there are clearly
defined entry points to catch all exceptions and inform the user.  I took a
slightly different approach when using JSword but found I still needed the
top level try/catch blocks that I used with RuntimeExceptions but also
needed the try/catch in the code for the sake of JSword's checked
exceptions.

Prof Martin Odersky would totally agree with you because in Scala all
exceptions are RuntimeExceptions.

The only problem I can see is it would not be easy to retain backward
compatibility so as not to break existing apps.

Regards
Martin



On 27 February 2011 10:41, Chris Burrell <chris at burrell.me.uk> wrote:

> Hi
>
> Can I assume that exception handling in JSword is all be done via a
> LucidException? It doesn't look like LucidRuntimeExceptions are being used
> much...
>
> I myself would prefer to be handling RuntimeException (i.e.
> LucidRuntimeException) as that would mean less explicit handling. For
> example, if I have someone ask for a verse that doesn't exist, my default
> behaviour will be to stop the processing, bubble up to the top and handle it
> there. I'd like to catch that exception as high up as possible without
> explicitly needing to specify it on every method that it might go through -
> clutters our code a little.
>
> Any thoughts?
>
> Cheers
> Chris
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110302/78829e2a/attachment.html>

From christopher at burrell.me.uk  Wed Mar  2 14:58:15 2011
From: christopher at burrell.me.uk (Chris Burrell)
Date: Wed, 2 Mar 2011 21:58:15 +0000
Subject: [jsword-devel] Exception bubbling
In-Reply-To: <AANLkTimKQRF9T7yCi5uismtX9v=w-BtbrisBxdOeTACm@mail.gmail.com>
References: <AANLkTinzs1=L3GgHRriEPOUG4MNdQY6nnjnV1sR8v54U@mail.gmail.com>
 <AANLkTimKQRF9T7yCi5uismtX9v=w-BtbrisBxdOeTACm@mail.gmail.com>
Message-ID: <AANLkTinLnUYPYkH85=hkPVv-r412w02kH0zcssP+HQLN@mail.gmail.com>

I'm not sure I agree about backwards compatibility...

Can't we in the first instance change the LucidException to extend a
RuntimeException. Then all the apps currently handling the exception can
still handle it. Secondly we change the method signature. And still the
existing apps could catch these exceptions. I believe you can catch any type
of RuntimeException, whenever you like. So existing apps would be fine? The
only think you can't do is to catch a checked exception that is not
declared... (or of course not catch a declared exception).

So for example, existing code catching a NoSuchVerseException will
effectively be catching a different type of object, but it is still an
exception and still valid to be caught...

Chris


On 2 March 2011 21:50, Martin Denham <mjdenham at gmail.com> wrote:

> I tend to use RuntimeExceptions with web apps where there are clearly
> defined entry points to catch all exceptions and inform the user.  I took a
> slightly different approach when using JSword but found I still needed the
> top level try/catch blocks that I used with RuntimeExceptions but also
> needed the try/catch in the code for the sake of JSword's checked
> exceptions.
>
> Prof Martin Odersky would totally agree with you because in Scala all
> exceptions are RuntimeExceptions.
>
> The only problem I can see is it would not be easy to retain backward
> compatibility so as not to break existing apps.
>
> Regards
> Martin
>
>
>
> On 27 February 2011 10:41, Chris Burrell <chris at burrell.me.uk> wrote:
>
>> Hi
>>
>> Can I assume that exception handling in JSword is all be done via a
>> LucidException? It doesn't look like LucidRuntimeExceptions are being used
>> much...
>>
>> I myself would prefer to be handling RuntimeException (i.e.
>> LucidRuntimeException) as that would mean less explicit handling. For
>> example, if I have someone ask for a verse that doesn't exist, my default
>> behaviour will be to stop the processing, bubble up to the top and handle it
>> there. I'd like to catch that exception as high up as possible without
>> explicitly needing to specify it on every method that it might go through -
>> clutters our code a little.
>>
>> Any thoughts?
>>
>> Cheers
>> Chris
>>
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110302/dbb82ddd/attachment.html>

From dmsmith at crosswire.org  Wed Mar  2 18:37:25 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Wed, 2 Mar 2011 20:37:25 -0500
Subject: [jsword-devel] Error with Strongs tags in Russian RST bible
In-Reply-To: <AANLkTimm6OAf45_gywo-a1yVPaUdU6Z+NB8pKVdSC8cd@mail.gmail.com>
References: <AANLkTimyWhGYSryauoU8uO57Wa8G8qrd34wH1w4m3VEY@mail.gmail.com>
 <6A12B600-6195-4698-A7CD-572C42474411@crosswire.org>
 <F964BE86-2953-4523-9906-4868E4011567@crosswire.org>
 <AANLkTinN8fbPF34UwOAY8A5UgSBSFnf0nnzKZzgWe0Dm@mail.gmail.com>
 <AANLkTimm6OAf45_gywo-a1yVPaUdU6Z+NB8pKVdSC8cd@mail.gmail.com>
Message-ID: <6A5D4610-DABD-4453-BB84-71AA2621FBBC@crosswire.org>


On Mar 2, 2011, at 4:20 PM, Martin Denham wrote:

> It's strange that the JS-166 JIRA notification didn't come through via e-mail like new JIRAs normally do.
Mail was down yesterday. I think some mails were lost.

In Him,
	DM



From jira at crosswire.org  Wed Mar  2 20:29:41 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 2 Mar 2011 20:29:41 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-167) Allow MsgBase to find
 message files outside of package
Message-ID: <1802278050.8.1299122981213.JavaMail.tomcat@www.crosswire.org>

Allow MsgBase to find message files outside of package
------------------------------------------------------

                 Key: JS-167
                 URL: http://www.crosswire.org/bugs/browse/JS-167
             Project: JSword
          Issue Type: Bug
          Components: o.c.common.util
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
            Priority: Minor
             Fix For: 1.6.1


Today, message files can only be in the directory in which the derived Msg class is defined. Allow the file to be named and located anywhere that JSword finds files.

This allows for internationalization to happen by placing the translations in ~/.jsword.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  2 20:33:40 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 2 Mar 2011 20:33:40 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-168) SectionNames should not
	extend MsgBase
Message-ID: <1075030493.10.1299123220986.JavaMail.tomcat@www.crosswire.org>

SectionNames should not extend MsgBase
--------------------------------------

                 Key: JS-168
                 URL: http://www.crosswire.org/bugs/browse/JS-168
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.versification
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


SectionNames is no longer a source of messages. They have migrated into UserMsg.properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  2 20:46:40 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 2 Mar 2011 20:46:40 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-104) Migrate translations into
 as few files as possible and co-locate them
Message-ID: <1941540195.12.1299124000923.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053#comment-14053 ] 

DM Smith commented on JS-104:
-----------------------------

Major merging of Msg into BibleDesktopMsg.
Need to merge config into it.
Restored missing SiteEditorFactory.properties and renamed it SiteEditor.plugin.
Move most resources to src/main/resources.

> Migrate translations into as few files as possible and co-locate them
> ---------------------------------------------------------------------
>
>                 Key: JS-104
>                 URL: http://www.crosswire.org/bugs/browse/JS-104
>             Project: JSword
>          Issue Type: Improvement
>          Components: o.c.jsword.util
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>         Attachments: JS-104-1.patch.zip
>
>
> Translating Common, JSword and BibleDesktop is difficult as translations files are segregated by Java package. As such there has been little traction in translating Bible Desktop into other languages.
> Translations should be co-located in a single location. The translator should not have to dig to find the files to translate. By having them co-located, the translator can quickly find what has and has not been translated. 
> Translations should be able to be edited in their native script. Java property files are in ASCII and are not conducive to editing. 
> Translators should be able to edit the files easily outside of Eclipse using a simple translation editor such as poedit. 
> The conversion of these files to Java property files should be automated. 
> Recommendation: Explore GNU's "Translation Project." Specifically, gettext "po" files. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From chris at burrell.me.uk  Thu Mar  3 11:44:41 2011
From: chris at burrell.me.uk (Chris Burrell)
Date: Thu, 3 Mar 2011 18:44:41 +0000
Subject: [jsword-devel] Concurrency issue?
In-Reply-To: <4D6C0C80.5070200@crosswire.org>
References: <AANLkTike3gniwtZnME5vtkBrpBCpNQWrcJYXURkUzuzR@mail.gmail.com>
 <AANLkTinUQ+56DgaGMe=C8g5Oh-Er1JwjGSAHHP4k9boq@mail.gmail.com>
 <4D6C0C80.5070200@crosswire.org>
Message-ID: <AANLkTikUQNFwOU9TB6Tbi+Xwwpv7bMLGBDThNZa--Hv1@mail.gmail.com>

Thanks DM, I've now managed to narrow down the problem and have a unit test
that replicates the issue:

Could someone lend me a hand and run a simple junit test to test this on
another environment? The test below fails on my laptop (java 1.6 update 22)
with that particular error I described earlier.

    @Test
    public void testConcurrencyIssueOnBookData() throws NoSuchKeyException,
BookException,
            InterruptedException {
        final String name = "KJV";
        final String ref = "Rom.1.1";

        final Runnable t = new Runnable() {
            @Override
            public void run() {
                final Book b0 = Books.installed().getBook(name);
                BookData bd1;
                try {
                    bd1 = new BookData(b0, b0.getKey(ref));
*                    bd1.getSAXEventProvider();*
                } catch (final NoSuchKeyException e) {
                    e.printStackTrace();
                } catch (final BookException e) {
                    e.printStackTrace();
                }

            }
        };

        int ii = 0;
        while (ii++ < 1000) {
            final Thread t1 = new Thread(t);
            final Thread t2 = new Thread(t);
            t1.start();
            t2.start();

            t1.join();
            t2.join();
        }
    }

The issue I have in the test above occurs with this line:
                    bd1.getSAXEventProvider(); (bold above)

If I put a breakpoint on the call to getSAXEventProvider and let one thread
run through things look alright. If I put it line below, I get one of three
scenarios. (so we may be looking at a couple of bugs)

75% stacktrace as below
20% no text returned, or garbled text (e.g. cross refs showing in the text
displayed when they weren't asked for...)
5% it works

If someone could try and run it and feedback that would be helpful (running
latest version of jsword)
Chris


On 28 February 2011 20:58, DM Smith <dmsmith at crosswire.org> wrote:

>  Chris,
>
> I haven't seen your problem before. However,
>
> The line:
>     requiredTransformation.iterator().next().getFile()
> looks suspicious as the contract to iterator requires calling hasNext()
> before calling next() and only calling next() when hasNext() returns true.
>
> The reason for this is that hasNext() typically sets up what next()
> returns.
>
> Some implementations of an iterator will have the constructor setting up
> the first value to return and having next() do double duty of setting up the
> next value and returning the current value. In this case repeatedly calling
> next might work.
>
> Also calling, iterator().next(), if calling next() without hasNext() works,
> should only ever return the first value as the call to iterator should set
> up a fresh iterator.
>
> In Him,
>     DM
>
>
> On 02/27/2011 05:37 PM, Chris Burrell wrote:
>
> The code I'm running into issues with is here. It could well be I'm
> mis-using the library?
> final SAXEventProvider osissep = bookData.getSAXEventProvider();
>             TransformingSAXEventProvider htmlsep = null;
>             htmlsep = (TransformingSAXEventProvider) new Converter() {
>
>                  public SAXEventProvider convert(final SAXEventProvider
> provider) throws TransformerException {
>                      try {
>                         // for now, we just assume that we'll only have one
> option, but this may change later
>                         // TODO, we can probably cache the resource
>                         final TransformingSAXEventProvider tsep = new
> TransformingSAXEventProvider(getClass()
>
> .getResource(requiredTransformation.iterator().next().getFile()).toURI(),
>                                 osissep);
>
>                          // set parameters here
>                         setOptions(tsep, options, version, reference);
>                         setupInterlinearOptions(tsep, interlinearVersion,
> reference);
>                         return tsep;
>                     } catch (final URISyntaxException e) {
>                         throw new StepInternalException("Failed to load
> resource correctly", e);
>                     }
>                 }
>
>              }.convert(osissep);
>
>
> On 27 February 2011 16:52, Chris Burrell <chris at burrell.me.uk> wrote:
>
>> Hello...
>>
>>  I was just wondering if someone has come across this issue before?
>>
>>  I have two panes loading two passages (1 ESV, 1 KJV). I am getting the
>> following issue fairly frequently. (this is different to the issue I raised
>> quite a while ago, in that the one before was corruption in the book reading
>> driver).
>>
>>  Caused by: java.lang.IllegalStateException: Root element not set
>>  at org.jdom.Document.getRootElement(Document.java:218)
>>  at
>> org.crosswire.jsword.book.filter.osis.OSISFilter.parse(OSISFilter.java:149)
>>  at
>> org.crosswire.jsword.book.filter.osis.OSISFilter.toOSIS(OSISFilter.java:74)
>>  at
>> org.crosswire.jsword.book.basic.AbstractPassageBook.getOsisIterator(AbstractPassageBook.java:90)
>>  at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
>>  at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
>>  at
>> org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
>>  at
>> com.tyndalehouse.step.core.service.impl.JSwordServiceImpl.getOsisText(JSwordServiceImpl.java:131)
>>  at
>> com.tyndalehouse.step.core.service.impl.BibleInformationServiceImpl.getPassageText(BibleInformationServiceImpl.java:57)
>>  at
>> com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:101)
>>  at
>> com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:60)
>>  ... 28 more
>>
>>  Also DM, have you started looking at JS-109? Just wondering...
>> Chris
>>
>>
>
> _______________________________________________
> jsword-devel mailing listjsword-devel at crosswire.orghttp://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110303/12cb8376/attachment.html>

From chris at burrell.me.uk  Thu Mar  3 12:57:12 2011
From: chris at burrell.me.uk (Chris Burrell)
Date: Thu, 3 Mar 2011 19:57:12 +0000
Subject: [jsword-devel] Concurrency issue?
In-Reply-To: <AANLkTikUQNFwOU9TB6Tbi+Xwwpv7bMLGBDThNZa--Hv1@mail.gmail.com>
References: <AANLkTike3gniwtZnME5vtkBrpBCpNQWrcJYXURkUzuzR@mail.gmail.com>
 <AANLkTinUQ+56DgaGMe=C8g5Oh-Er1JwjGSAHHP4k9boq@mail.gmail.com>
 <4D6C0C80.5070200@crosswire.org>
 <AANLkTikUQNFwOU9TB6Tbi+Xwwpv7bMLGBDThNZa--Hv1@mail.gmail.com>
Message-ID: <AANLkTikQFvgdO6uin_Wa47bhkuJYECBS=cwqTJRJs63B@mail.gmail.com>

Actually this is a better test, since it exercises two different books (the
one in the previous email succesfully re-creates JS-109 though)

    @Test
    public void testConcurrencyIssueOnBookData() throws NoSuchKeyException,
BookException,
            InterruptedException {
        final String[] names = { "KJV", "ESV" };
        final String ref = "Rom.1.1";

        final Runnable r1 = new Runnable() {
            @Override
            public void run() {
                final Book b0 = Books.installed().getBook(names[0]);
                BookData bd1;
                try {
                    bd1 = new BookData(b0, b0.getKey(ref));
                    bd1.getSAXEventProvider();
                } catch (final NoSuchKeyException e) {
                    e.printStackTrace();
                } catch (final BookException e) {
                    e.printStackTrace();
                }

            }
        };

        final Runnable r2 = new Runnable() {
            @Override
            public void run() {
                final Book b0 = Books.installed().getBook(names[1]);
                BookData bd1;
                try {
                    bd1 = new BookData(b0, b0.getKey(ref));
                    bd1.getSAXEventProvider();
                } catch (final NoSuchKeyException e) {
                    e.printStackTrace();
                } catch (final BookException e) {
                    e.printStackTrace();
                }

            }
        };

        int ii = 0;
        while (ii++ < 1000) {
            final Thread t1 = new Thread(r1);
            final Thread t2 = new Thread(r2);
            t1.start();
            t2.start();

            t1.join();
            t2.join();
        }
    }


On 3 March 2011 18:44, Chris Burrell <chris at burrell.me.uk> wrote:

> Thanks DM, I've now managed to narrow down the problem and have a unit test
> that replicates the issue:
>
> Could someone lend me a hand and run a simple junit test to test this on
> another environment? The test below fails on my laptop (java 1.6 update 22)
> with that particular error I described earlier.
>
>     @Test
>     public void testConcurrencyIssueOnBookData() throws NoSuchKeyException,
> BookException,
>             InterruptedException {
>         final String name = "KJV";
>         final String ref = "Rom.1.1";
>
>         final Runnable t = new Runnable() {
>             @Override
>             public void run() {
>                 final Book b0 = Books.installed().getBook(name);
>                 BookData bd1;
>                 try {
>                     bd1 = new BookData(b0, b0.getKey(ref));
> *                    bd1.getSAXEventProvider();*
>                 } catch (final NoSuchKeyException e) {
>                     e.printStackTrace();
>                 } catch (final BookException e) {
>                     e.printStackTrace();
>                 }
>
>             }
>         };
>
>         int ii = 0;
>         while (ii++ < 1000) {
>             final Thread t1 = new Thread(t);
>             final Thread t2 = new Thread(t);
>             t1.start();
>             t2.start();
>
>             t1.join();
>             t2.join();
>         }
>     }
>
> The issue I have in the test above occurs with this line:
>                     bd1.getSAXEventProvider(); (bold above)
>
> If I put a breakpoint on the call to getSAXEventProvider and let one thread
> run through things look alright. If I put it line below, I get one of three
> scenarios. (so we may be looking at a couple of bugs)
>
> 75% stacktrace as below
> 20% no text returned, or garbled text (e.g. cross refs showing in the text
> displayed when they weren't asked for...)
> 5% it works
>
> If someone could try and run it and feedback that would be helpful (running
> latest version of jsword)
> Chris
>
>
> On 28 February 2011 20:58, DM Smith <dmsmith at crosswire.org> wrote:
>
>>  Chris,
>>
>> I haven't seen your problem before. However,
>>
>> The line:
>>     requiredTransformation.iterator().next().getFile()
>> looks suspicious as the contract to iterator requires calling hasNext()
>> before calling next() and only calling next() when hasNext() returns true.
>>
>> The reason for this is that hasNext() typically sets up what next()
>> returns.
>>
>> Some implementations of an iterator will have the constructor setting up
>> the first value to return and having next() do double duty of setting up the
>> next value and returning the current value. In this case repeatedly calling
>> next might work.
>>
>> Also calling, iterator().next(), if calling next() without hasNext()
>> works, should only ever return the first value as the call to iterator
>> should set up a fresh iterator.
>>
>> In Him,
>>     DM
>>
>>
>> On 02/27/2011 05:37 PM, Chris Burrell wrote:
>>
>> The code I'm running into issues with is here. It could well be I'm
>> mis-using the library?
>> final SAXEventProvider osissep = bookData.getSAXEventProvider();
>>             TransformingSAXEventProvider htmlsep = null;
>>             htmlsep = (TransformingSAXEventProvider) new Converter() {
>>
>>                  public SAXEventProvider convert(final SAXEventProvider
>> provider) throws TransformerException {
>>                      try {
>>                         // for now, we just assume that we'll only have
>> one option, but this may change later
>>                         // TODO, we can probably cache the resource
>>                         final TransformingSAXEventProvider tsep = new
>> TransformingSAXEventProvider(getClass()
>>
>> .getResource(requiredTransformation.iterator().next().getFile()).toURI(),
>>                                 osissep);
>>
>>                          // set parameters here
>>                         setOptions(tsep, options, version, reference);
>>                         setupInterlinearOptions(tsep, interlinearVersion,
>> reference);
>>                         return tsep;
>>                     } catch (final URISyntaxException e) {
>>                         throw new StepInternalException("Failed to load
>> resource correctly", e);
>>                     }
>>                 }
>>
>>              }.convert(osissep);
>>
>>
>> On 27 February 2011 16:52, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>>> Hello...
>>>
>>>  I was just wondering if someone has come across this issue before?
>>>
>>>  I have two panes loading two passages (1 ESV, 1 KJV). I am getting the
>>> following issue fairly frequently. (this is different to the issue I raised
>>> quite a while ago, in that the one before was corruption in the book reading
>>> driver).
>>>
>>>  Caused by: java.lang.IllegalStateException: Root element not set
>>>  at org.jdom.Document.getRootElement(Document.java:218)
>>>  at
>>> org.crosswire.jsword.book.filter.osis.OSISFilter.parse(OSISFilter.java:149)
>>>  at
>>> org.crosswire.jsword.book.filter.osis.OSISFilter.toOSIS(OSISFilter.java:74)
>>>  at
>>> org.crosswire.jsword.book.basic.AbstractPassageBook.getOsisIterator(AbstractPassageBook.java:90)
>>>  at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
>>>  at
>>> org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
>>>  at
>>> org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
>>>  at
>>> com.tyndalehouse.step.core.service.impl.JSwordServiceImpl.getOsisText(JSwordServiceImpl.java:131)
>>>  at
>>> com.tyndalehouse.step.core.service.impl.BibleInformationServiceImpl.getPassageText(BibleInformationServiceImpl.java:57)
>>>  at
>>> com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:101)
>>>  at
>>> com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:60)
>>>  ... 28 more
>>>
>>>  Also DM, have you started looking at JS-109? Just wondering...
>>> Chris
>>>
>>>
>>
>> _______________________________________________
>> jsword-devel mailing listjsword-devel at crosswire.orghttp://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110303/c223f82c/attachment.html>

From jira at crosswire.org  Sun Mar  6 21:09:49 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sun, 6 Mar 2011 21:09:49 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-169) Use varargs for messages
Message-ID: <1332746870.31.1299470989160.JavaMail.tomcat@www.crosswire.org>

Use varargs for messages
------------------------

                 Key: JS-169
                 URL: http://www.crosswire.org/bugs/browse/JS-169
             Project: JSword
          Issue Type: Sub-task
          Components: o.c.common.progress
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


Using varargs for messages will simplify the MsgBase class.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From dmsmith at crosswire.org  Sun Mar  6 21:49:42 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Sun, 6 Mar 2011 23:49:42 -0500
Subject: [jsword-devel] Fwd: Your message to jsword-svn awaits moderator
	approval
References: <mailman.130.1299471332.2103.jsword-svn@crosswire.org>
Message-ID: <831DF1E3-D717-4C09-B739-A0A702088BEF@crosswire.org>


This is one of two checkins. 

Begin forwarded message:

> From: jsword-svn-bounces at crosswire.org
> Date: March 6, 2011 11:15:32 PM EST
> To: dmsmith at crosswire.org
> Subject: Your message to jsword-svn awaits moderator approval
> 
> Your mail to 'jsword-svn' with the subject
> 
>    r2091 - in trunk:
> bibledesktop/src/main/java/org/crosswire/bibledesktop
> bibledesktop/src/main/java/org/crosswire/bibledesktop/book
> bibledesktop/src/main/java/org/crosswire/bibledesktop/book/install
> bibledesktop/src/main/java/org/crosswire/bibledesktop/desktop
> bibledesktop/src/main/java/org/crosswire/bibledesktop/display/basic
> bibledesktop/src/main/java/org/crosswire/bibledesktop/passage
> bibledesktop/src/main/resources
> bibledesktop/src/main/resources/org/crosswire/bibledesktop
> common-swing/src/main/java/org/crosswire/common/config/swing
> common-swing/src/main/java/org/crosswire/common/progress/swing
> common-swing/src/main/java/org/crosswire/common/swing
> common-swing/src/main/resources/org/crosswire/common/config/swing
> common-swing/src/main/resources/org/crosswire/common/swing
> 
> Is being held until the list moderator can review it for approval.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110306/2ef9a38e/attachment.html>

From dmsmith at crosswire.org  Sun Mar  6 21:53:18 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Sun, 6 Mar 2011 23:53:18 -0500
Subject: [jsword-devel] Big Checkin.
References: <mailman.127.1299471187.2103.jsword-svn@crosswire.org>
Message-ID: <8B541BF9-DF95-4717-8399-055D9FEED204@crosswire.org>


This is another of two checkins. 


Begin forwarded message:

> From: jsword-svn-bounces at crosswire.org
> Date: March 6, 2011 11:13:07 PM EST
> To: dmsmith at crosswire.org
> Subject: Your message to jsword-svn awaits moderator approval
> 
> Your mail to 'jsword-svn' with the subject
> 
>    r2090 - in trunk: jsword/src/main/java/gnu/gpl
> jsword/src/main/java/gnu/lgpl
> jsword/src/main/java/org/crosswire/common/activate
> jsword/src/main/java/org/crosswire/common/config
> jsword/src/main/java/org/crosswire/common/diff
> jsword/src/main/java/org/crosswire/common/history
> jsword/src/main/java/org/crosswire/common/icu
> jsword/src/main/java/org/crosswire/common/options
> jsword/src/main/java/org/crosswire/common/progress
> jsword/src/main/java/org/crosswire/common/util
> jsword/src/main/java/org/crosswire/common/xml
> jsword/src/main/java/org/crosswire/jsword/book
> jsword/src/main/java/org/crosswire/jsword/book/basic
> jsword/src/main/java/org/crosswire/jsword/book/filter
> jsword/src/main/java/org/crosswire/jsword/book/filter/gbf
> jsword/src/main/java/org/crosswire/jsword/book/filter/osis
> jsword/src/main/java/org/crosswire/jsword/book/filter/thml
> jsword/src/main/java/org/crosswire/jsword/book/install
> jsword/src/main/java/org/crosswire/jsword/book/install/sword
> jsword/src/main/java/org/crosswire/jsword/book/readings
> jsword/src/main/java/org/crosswire/jsword/book/study
> jsword/src/main/java/org/crosswire/jsword/book/sword
> jsword/src/main/java/org/crosswire/jsword/bridge
> jsword/src/main/java/org/crosswire/jsword/examples
> jsword/src/main/java/org/crosswire/jsword/index/lucene
> jsword/src/main/java/org/crosswire/jsword/index/query
> jsword/src/main/java/org/crosswire/jsword/passage
> jsword/src/main/java/org/crosswire/jsword/util
> jsword/src/main/java/org/crosswire/jsword/versification
> jsword/src/main/resources/org/crosswire/common
> jsword/src/main/resources/org/crosswire/common/config
> jsword/src/main/resources/org/crosswire/jsword/book
> jsword/src/main/resources/org/crosswire/jsword/book/basic
> jsword/src/main/resources/org/crosswire/jsword/book/filter
> jsword/src/main/resources/org/crosswire/jsword/book/install/sword
> jsword/src/main/resources/org/crosswire/jsword/book/readings
> jsword/src/main/resources/org/crosswire/jsword/book/sword
> jsword/src/main/resources/org/crosswire/jsword/passage
> jsword/src/main/resources/org/crosswire/jsword/util
> jsword/src/main/resources/org/crosswire/jsword/versification
> jsword/src/test/java/org/crosswire/common/diff
> jsword/src/test/java/org/crosswire/jsword/passage
> jsword-web/src/main/java/org/crosswire/jsword/view/web
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110306/37332cb2/attachment.html>

From jira at crosswire.org  Mon Mar  7 06:27:32 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Mon, 7 Mar 2011 06:27:32 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-170)
 GenBookBackend.contains(key) throws NPE if key not found
Message-ID: <1359119508.10.1299504452370.JavaMail.tomcat@www.crosswire.org>

GenBookBackend.contains(key) throws NPE if key not found
--------------------------------------------------------

                 Key: JS-170
                 URL: http://www.crosswire.org/bugs/browse/JS-170
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.book.sword
    Affects Versions: 1.6
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


I think there is a bug in GenBookBackend.contains(Key).  
The find method will return null if the key is not in the book
            TreeNode node = find(key);
which means the next line will throw a NullPointerException
            byte[] userData = node.getUserData();

Here is the whole method:
    @Override
    public boolean contains(Key key) {
        checkActive();

        try {
            DataPolice.setKey(key);
            TreeNode node = find(key);
            byte[] userData = node.getUserData();

            // Some entries may be empty.
            return userData.length == 8;
        } catch (IOException e) {
            return false;
        } finally {
            DataPolice.setKey(null);
        }
    }


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Mon Mar  7 06:54:32 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Mon, 7 Mar 2011 06:54:32 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-170)
 GenBookBackend.contains(key) throws NPE if key not found
In-Reply-To: <1359119508.10.1299504452370.JavaMail.tomcat@www.crosswire.org>
Message-ID: <2040355342.11.1299506072469.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072#comment-14072 ] 

Martin Denham commented on JS-170:
----------------------------------

A simple fix is to add a simple null check as below:

    public boolean contains(Key key) {
        checkActive();

        try {
            DataPolice.setKey(key);
            TreeNode node = find(key);

            if (node==null) {
                return false;
            }

            byte[] userData = node.getUserData();

            // Some entries may be empty.
            return userData.length == 8;
        } catch (IOException e) {
            return false;
        } finally {
            DataPolice.setKey(null);
        }
    }


> GenBookBackend.contains(key) throws NPE if key not found
> --------------------------------------------------------
>
>                 Key: JS-170
>                 URL: http://www.crosswire.org/bugs/browse/JS-170
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.sword
>    Affects Versions: 1.6
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think there is a bug in GenBookBackend.contains(Key).  
> The find method will return null if the key is not in the book
>             TreeNode node = find(key);
> which means the next line will throw a NullPointerException
>             byte[] userData = node.getUserData();
> Here is the whole method:
>     @Override
>     public boolean contains(Key key) {
>         checkActive();
>         try {
>             DataPolice.setKey(key);
>             TreeNode node = find(key);
>             byte[] userData = node.getUserData();
>             // Some entries may be empty.
>             return userData.length == 8;
>         } catch (IOException e) {
>             return false;
>         } finally {
>             DataPolice.setKey(null);
>         }
>     }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Mon Mar  7 06:54:33 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Mon, 7 Mar 2011 06:54:33 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-170)
 GenBookBackend.contains(key) throws NPE if key not found
In-Reply-To: <1359119508.10.1299504452370.JavaMail.tomcat@www.crosswire.org>
Message-ID: <481371643.13.1299506073590.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073#comment-14073 ] 

DM Smith commented on JS-170:
-----------------------------

I just checked in a fix for this. Let me know if it works for you.

> GenBookBackend.contains(key) throws NPE if key not found
> --------------------------------------------------------
>
>                 Key: JS-170
>                 URL: http://www.crosswire.org/bugs/browse/JS-170
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.sword
>    Affects Versions: 1.6
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think there is a bug in GenBookBackend.contains(Key).  
> The find method will return null if the key is not in the book
>             TreeNode node = find(key);
> which means the next line will throw a NullPointerException
>             byte[] userData = node.getUserData();
> Here is the whole method:
>     @Override
>     public boolean contains(Key key) {
>         checkActive();
>         try {
>             DataPolice.setKey(key);
>             TreeNode node = find(key);
>             byte[] userData = node.getUserData();
>             // Some entries may be empty.
>             return userData.length == 8;
>         } catch (IOException e) {
>             return false;
>         } finally {
>             DataPolice.setKey(null);
>         }
>     }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From dmsmith at crosswire.org  Mon Mar  7 06:56:08 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Mon, 7 Mar 2011 08:56:08 -0500
Subject: [jsword-devel] Another big checkin
References: <mailman.136.1299505731.2103.jsword-svn@crosswire.org>
Message-ID: <575CB71B-5B05-42AF-962A-0FCC234CCE64@crosswire.org>

I'm flattening src/main/resources in an attempt to improve/minimize the effort to do translations. These are just the files that did not have to be merged.

Begin forwarded message:

> Your mail to 'jsword-svn' with the subject
> 
>    r2096 - in trunk/jsword: .
> src/main/java/org/crosswire/jsword/versification src/main/resources
> src/main/resources/org/crosswire/common/config
> src/main/resources/org/crosswire/common/util
> src/main/resources/org/crosswire/common/xml
> src/main/resources/org/crosswire/jsword/book
> src/main/resources/org/crosswire/jsword/book/filter
> src/main/resources/org/crosswire/jsword/book/install
> src/main/resources/org/crosswire/jsword/book/install/sword
> src/main/resources/org/crosswire/jsword/book/readings
> src/main/resources/org/crosswire/jsword/index
> src/main/resources/org/crosswire/jsword/index/lucene
> src/main/resources/org/crosswire/jsword/index/lucene/analysis
> src/main/resources/org/crosswire/jsword/index/query
> src/main/resources/org/crosswire/jsword/index/search
> src/main/resources/org/crosswire/jsword/versification



From jira at crosswire.org  Mon Mar  7 18:19:32 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Mon, 7 Mar 2011 18:19:32 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-163) Create nexus repository
In-Reply-To: <1272700051.4.1298132002909.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1103163658.18.1299547172989.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074#comment-14074 ] 

DM Smith commented on JS-163:
-----------------------------

It will be straight forward to add the nexus war to tomcat, which is port 8080. But I'll need Troy to allow it through the firewall on port 80.

> Create nexus repository
> -----------------------
>
>                 Key: JS-163
>                 URL: http://www.crosswire.org/bugs/browse/JS-163
>             Project: JSword
>          Issue Type: Sub-task
>          Components: build
>            Reporter: Chris Burrell
>            Assignee: DM Smith
>            Priority: Blocker
>             Fix For: 1.6.1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Mon Mar  7 18:37:33 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Mon, 7 Mar 2011 18:37:33 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-171) Upgrade JUnit to 4.x
Message-ID: <43921423.20.1299548253267.JavaMail.tomcat@www.crosswire.org>

Upgrade JUnit to 4.x
--------------------

                 Key: JS-171
                 URL: http://www.crosswire.org/bugs/browse/JS-171
             Project: JSword
          Issue Type: Improvement
          Components: build
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


We have been on JUnit 3.x because 4.x requires Java 5. Now we are using Java 5. So now we can upgrade to the latest and greatest.

Re-write the tests to use 4.x.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Tue Mar  8 02:00:32 2011
From: jira at crosswire.org (Chris Burrell (JIRA))
Date: Tue, 8 Mar 2011 02:00:32 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-171) Upgrade JUnit to 4.x
In-Reply-To: <43921423.20.1299548253267.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1710911290.22.1299574832950.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077#comment-14077 ] 

Chris Burrell commented on JS-171:
----------------------------------

A consideration when rewriting those is about concurrency. Bearing that in mind means you'll be able to run your tests concurrently on a method or class level, meaning build times will be faster.

> Upgrade JUnit to 4.x
> --------------------
>
>                 Key: JS-171
>                 URL: http://www.crosswire.org/bugs/browse/JS-171
>             Project: JSword
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> We have been on JUnit 3.x because 4.x requires Java 5. Now we are using Java 5. So now we can upgrade to the latest and greatest.
> Re-write the tests to use 4.x.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Tue Mar  8 03:59:47 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Tue, 8 Mar 2011 03:59:47 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-172) Covariant clone
Message-ID: <295300014.1.1299581987308.JavaMail.tomcat@www.crosswire.org>

Covariant clone
---------------

                 Key: JS-172
                 URL: http://www.crosswire.org/bugs/browse/JS-172
             Project: JSword
          Issue Type: Sub-task
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


Covariant clones simplify calls to clone as they don't return Object but the class in which they are defined.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Tue Mar  8 15:52:46 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Tue, 8 Mar 2011 15:52:46 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-173) Error reading GenBook
	(Pilgrim's Progress)
Message-ID: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>

Error reading GenBook (Pilgrim's Progress)
------------------------------------------

                 Key: JS-173
                 URL: http://www.crosswire.org/bugs/browse/JS-173
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.book.filter.thml
    Affects Versions: 1.6.1
         Environment: Windows and Android
            Reporter: Martin Denham
            Assignee: DM Smith


I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.

Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line

	Book book = getBook("Pilgrim");
	Key key = book.getKey("THE FIRST STAGE");
	BookData data = new BookData(book, key);		
	SAXEventProvider osissep = data.getSAXEventProvider();

Here is the StackTrace:
org.jdom.IllegalAddException: The Content already has an existing parent "seg"
	at org.jdom.ContentList.add(ContentList.java:209)
	at org.jdom.ContentList.add(ContentList.java:131)
	at org.jdom.ContentList.addAll(ContentList.java:283)
	at org.jdom.ContentList.addAll(ContentList.java:253)
	at org.jdom.Element.addContent(Element.java:827)
	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 05:08:35 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Wed, 9 Mar 2011 05:08:35 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-174) Infinite recursion getting
 osis id for a TreeKey
Message-ID: <1966455976.0.1299672515582.JavaMail.tomcat@www.crosswire.org>

Infinite recursion getting osis id for a TreeKey
------------------------------------------------

                 Key: JS-174
                 URL: http://www.crosswire.org/bugs/browse/JS-174
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.passage
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


I am not sure if it makes sense to get an osis id for a TreeKey treeKey.getName works fine but when I tried treeKey.getOsisID it failed with some sort of infinite recursion error.  I wonder if the new java 5 for loop in KeyUtil.visit is causing a problem.

Here is my test:
	Book book = getBook("Pilgrim");  // Bunyan's Pilgrim's Progress
	Key key = book.getKey("THE FIRST STAGE");
	key.getOsisID(); // error occurs here

Here is the top of the stack trace:
java.lang.StackOverflowError
	at java.util.Stack.peek(Stack.java:86)
	at org.crosswire.jsword.passage.KeyIterator.prepare(KeyIterator.java:49)
	at org.crosswire.jsword.passage.KeyIterator.hasNext(KeyIterator.java:63)
	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:68)
	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:36)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:50)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
// the calls to .visit go on and on...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 05:15:36 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 9 Mar 2011 05:15:36 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-174) Infinite recursion
 getting osis id for a TreeKey
In-Reply-To: <1966455976.0.1299672515582.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1553599394.2.1299672936122.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081#comment-14081 ] 

DM Smith commented on JS-174:
-----------------------------

Thanks for such a focused test. This will help finding the fix. 

> Infinite recursion getting osis id for a TreeKey
> ------------------------------------------------
>
>                 Key: JS-174
>                 URL: http://www.crosswire.org/bugs/browse/JS-174
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I am not sure if it makes sense to get an osis id for a TreeKey treeKey.getName works fine but when I tried treeKey.getOsisID it failed with some sort of infinite recursion error.  I wonder if the new java 5 for loop in KeyUtil.visit is causing a problem.
> Here is my test:
> 	Book book = getBook("Pilgrim");  // Bunyan's Pilgrim's Progress
> 	Key key = book.getKey("THE FIRST STAGE");
> 	key.getOsisID(); // error occurs here
> Here is the top of the stack trace:
> java.lang.StackOverflowError
> 	at java.util.Stack.peek(Stack.java:86)
> 	at org.crosswire.jsword.passage.KeyIterator.prepare(KeyIterator.java:49)
> 	at org.crosswire.jsword.passage.KeyIterator.hasNext(KeyIterator.java:63)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:68)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:36)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:50)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> // the calls to .visit go on and on...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 07:01:43 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 9 Mar 2011 07:01:43 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1709644192.4.1299679303607.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082#comment-14082 ] 

DM Smith commented on JS-173:
-----------------------------

The problem is in the code:
        Element parent = ele.getParentElement();
        parent.removeContent(ele);
        parent.addContent(ele.getChildren());
It throws an IllegalAddException (a RuntimeException) on the third line.
The fix is straightforward, it needs to be something like:

for each child in ele.getChildren
do
 ele.removeContent(child)
 parent.addContent(child);
done

The other problem is that ThMLFilter.parse does not trap the exception. The intention of toOSIS is to always return the text in the entry, even if it looks ugly. So it needs to trap all exceptions.

I should have a fix for both soon.

> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 10:01:36 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 9 Mar 2011 10:01:36 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (BD-169) replace icons from jlfgr.jar
Message-ID: <1967072805.6.1299690096909.JavaMail.tomcat@www.crosswire.org>

replace icons from jlfgr.jar
----------------------------

                 Key: BD-169
                 URL: http://www.crosswire.org/bugs/browse/BD-169
             Project: Bible Desktop
          Issue Type: Improvement
          Components: utilities
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
            Priority: Trivial
             Fix For: 1.6.1


The jlfgr jar contains icons from Sun, now Oracle.

They were a nice way to get "standard" icons. However, they never became "standard".

By replacing them, we simplify dependencies and help our development of maven builds.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 10:25:39 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 9 Mar 2011 10:25:39 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (BD-169) replace icons from
	jlfgr.jar
In-Reply-To: <1967072805.6.1299690096909.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1467483723.8.1299691539549.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/BD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083#comment-14083 ] 

DM Smith commented on BD-169:
-----------------------------

It would be good to get vector graphics for these and convert that to images so that we can have appropriate sized images.

The description of the icons is here:
http://java.sun.com/developer/techDocs/hi/repository/

Here is a listing of what Bible Desktop:
(Note: cut and paste are not currently used, but are referenced in comments for future menu items.)
toolbarButtonGraphics/general/About16.gif
toolbarButtonGraphics/general/About24.gif
toolbarButtonGraphics/general/ContextualHelp16.gif
toolbarButtonGraphics/general/Copy16.gif
toolbarButtonGraphics/general/Copy24.gif
toolbarButtonGraphics/general/Cut16.gif
toolbarButtonGraphics/general/Cut24.gif
toolbarButtonGraphics/general/Help16.gif
toolbarButtonGraphics/general/Help24.gif
toolbarButtonGraphics/general/Import16.gif
toolbarButtonGraphics/general/Import24.gif
toolbarButtonGraphics/general/New16.gif
toolbarButtonGraphics/general/New24.gif
toolbarButtonGraphics/general/Open16.gif
toolbarButtonGraphics/general/Open24.gif
toolbarButtonGraphics/general/Paste16.gif
toolbarButtonGraphics/general/Paste24.gif
toolbarButtonGraphics/general/Properties16.gif
toolbarButtonGraphics/general/Properties24.gif
toolbarButtonGraphics/general/Remove16.gif
toolbarButtonGraphics/general/Remove24.gif
toolbarButtonGraphics/general/Save16.gif
toolbarButtonGraphics/general/Save24.gif
toolbarButtonGraphics/general/SaveAll16.gif
toolbarButtonGraphics/general/SaveAll24.gif
toolbarButtonGraphics/general/SaveAs16.gif
toolbarButtonGraphics/general/SaveAs24.gif
toolbarButtonGraphics/general/Stop16.gif
toolbarButtonGraphics/general/Stop24.gif
toolbarButtonGraphics/navigation/Back16.gif
toolbarButtonGraphics/navigation/Back24.gif
toolbarButtonGraphics/navigation/Forward16.gif
toolbarButtonGraphics/navigation/Forward24.gif

> replace icons from jlfgr.jar
> ----------------------------
>
>                 Key: BD-169
>                 URL: http://www.crosswire.org/bugs/browse/BD-169
>             Project: Bible Desktop
>          Issue Type: Improvement
>          Components: utilities
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>            Priority: Trivial
>             Fix For: 1.6.1
>
>
> The jlfgr jar contains icons from Sun, now Oracle.
> They were a nice way to get "standard" icons. However, they never became "standard".
> By replacing them, we simplify dependencies and help our development of maven builds.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 11:16:39 2011
From: jira at crosswire.org (Chris Burrell (JIRA))
Date: Wed, 9 Mar 2011 11:16:39 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (BD-169) replace icons from
	jlfgr.jar
In-Reply-To: <1967072805.6.1299690096909.JavaMail.tomcat@www.crosswire.org>
Message-ID: <801482238.10.1299694599493.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/BD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084#comment-14084 ] 

Chris Burrell commented on BD-169:
----------------------------------

as far as Maven goes, it won't matter to have an external jar file once we have a nexus repository... So if you're happy with it as is, then i wouldn't go changing it just for Maven :)

> replace icons from jlfgr.jar
> ----------------------------
>
>                 Key: BD-169
>                 URL: http://www.crosswire.org/bugs/browse/BD-169
>             Project: Bible Desktop
>          Issue Type: Improvement
>          Components: utilities
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>            Priority: Trivial
>             Fix For: 1.6.1
>
>
> The jlfgr jar contains icons from Sun, now Oracle.
> They were a nice way to get "standard" icons. However, they never became "standard".
> By replacing them, we simplify dependencies and help our development of maven builds.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar  9 12:11:36 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 9 Mar 2011 12:11:36 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (BD-169) replace icons from
	jlfgr.jar
In-Reply-To: <1967072805.6.1299690096909.JavaMail.tomcat@www.crosswire.org>
Message-ID: <2097455554.17.1299697896170.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/BD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085#comment-14085 ] 

DM Smith commented on BD-169:
-----------------------------

Chris, it's not an issue with maven. We've had several suggestions for improved images. Usually, it is simply a matter of personal preference.

This really is part of a bigger desire:

Couple of goals:
# better looking icons, having a consistent look & feel
 We have a couple of icons (e.g. blur 1, blur 5, the "Book" icons) that are ugly.
# icons which are understandable in an international context
 The book icons are a letter corresponding to an English word for the category of books. (I think we have an open issue for this one.)
# icons which can be easily be replaced by a user
 By using a standard naming convention e.g. http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
 we can allow for a user to drop the set into ~/.jsword and have it replace the ones on the app. An example of this would be the Tango icons for Gnome/KDE. And if such a set were installed by the user on their machine (e.g. Linux) as a theme, then it'd be nice to use it.
# As monitor resolutions increase, the apparent size of the icons decreases. It'd be nice to allow for or be ready for "device independence".


> replace icons from jlfgr.jar
> ----------------------------
>
>                 Key: BD-169
>                 URL: http://www.crosswire.org/bugs/browse/BD-169
>             Project: Bible Desktop
>          Issue Type: Improvement
>          Components: utilities
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>            Priority: Trivial
>             Fix For: 1.6.1
>
>
> The jlfgr jar contains icons from Sun, now Oracle.
> They were a nice way to get "standard" icons. However, they never became "standard".
> By replacing them, we simplify dependencies and help our development of maven builds.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Thu Mar 10 07:29:03 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Thu, 10 Mar 2011 07:29:03 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1438263551.1.1299767343925.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090#comment-14090 ] 

DM Smith commented on JS-173:
-----------------------------

The fix for the reported problem is rather simple:
Change:
parent.addContent(ele.getChildren());
with
parent.addContent(ele.removeChildren());

Note: the original code was wrong, even if it worked. getChildren returns only the Element content, thus no direct Text children. It should have been ele.getContent();

This fix shows another problem. ThML is defined as xml, but PILGRIMS is sloppy in having <br> rather than <br/>. I'm working on this problem.

I suspect that there are <p> rather than <p>...</p> too.

Adding the trapping of the exception was easy. JDom defines three different IllegalArgumentExceptions, so these needed to be caught. I also found it was good to trap RuntimeException, and am in the process of seeing what is causing that.

However trapping exceptions also showed a different problem: stripping out the xml markup left words without intervening spaces.


> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Thu Mar 10 14:02:02 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Thu, 10 Mar 2011 14:02:02 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-175) indexOf a valid Key in
	Josephus returns -1
Message-ID: <1139788319.8.1299790922811.JavaMail.tomcat@www.crosswire.org>

indexOf a valid Key in Josephus returns -1
------------------------------------------

                 Key: JS-175
                 URL: http://www.crosswire.org/bugs/browse/JS-175
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.passage
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


Here is my test:

	Book book = getBook("Josephus");
	assertNotNull("Josephus not available", book);
	
	// find a key and print out it's name - this works
	final String SECTION_2 = "Section 2";
	Key key = book.getKey(SECTION_2);
	assertEquals(SECTION_2, key.getName());
	
	// but we can't get it's index - this returns -1
	int keyPos = book.getGlobalKeyList().indexOf(key);
	assertFalse("Could not get index of a valid key", -1==keyPos);

When dealing with a book having TreeKeys the top level Key returned by book.getGlobalKeyList is not a TreeKey but a KeyList which therefore does not automatically search it's children.  So I wonder if SwordGenBook.global could be a TreeKey rather than a ReadOnlyKeyList.

Maybe the way it works is the way it should work but I am not sure.  Now I realise what is happening I could just call indexOf on each child of the globalKeyList but I think it would be more elegant if globalKeyList.indexOf returned a key from lower down in the tree.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Thu Mar 10 15:17:02 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Thu, 10 Mar 2011 15:17:02 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-176) Incorrect resource text
 causing missing Missing Resource error
Message-ID: <564775860.9.1299795422827.JavaMail.tomcat@www.crosswire.org>

Incorrect resource text causing missing Missing Resource error
--------------------------------------------------------------

                 Key: JS-176
                 URL: http://www.crosswire.org/bugs/browse/JS-176
             Project: JSword
          Issue Type: Bug
          Components: o.c.common.util
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


IOUtil and NetUtil both contain messages like "The given URL {0} could not be created ... as a [file|directory]"

but UserMsg.properties contains "The URL {0} could not be created ... as a [file|directory]" without the word 'given'

So the word 'given' is missing from 2 messages in UserMsg.properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From chris at burrell.me.uk  Thu Mar 10 15:56:59 2011
From: chris at burrell.me.uk (Chris Burrell)
Date: Thu, 10 Mar 2011 22:56:59 +0000
Subject: [jsword-devel] New crosswire mailing list
Message-ID: <AANLkTinaK7iQwR7xzAdyxz965ZhLsTmtKN50R1g3pBW7@mail.gmail.com>

Hi All

For people interested in following the development of Tyndale STEP, a new
mailing list has been set up:

tyndale-devel at crosswire.org

Register here if you're interested:
http://www.crosswire.org/mailman/listinfo

Many thanks to Troy for setting this up

Cheers
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110310/dd74130d/attachment.html>

From jira at crosswire.org  Thu Mar 10 18:35:03 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Thu, 10 Mar 2011 18:35:03 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1903695465.11.1299807303764.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093#comment-14093 ] 

DM Smith commented on JS-173:
-----------------------------

There was code already to convert <br> to <br/> as well as a few other tags.
The plain RuntimeException was an artifact of trying to fix BrTag by having it return null. Didn't need to change that class.

I've changed XMLUtil methods that strip content to put a space for what is removed.

In BibleDesktop, I verified that I can read the entire module. But let me know if you see any problems.

> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Fri Mar 11 01:35:02 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Fri, 11 Mar 2011 01:35:02 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-175) indexOf a valid Key in
 Josephus returns -1
In-Reply-To: <1139788319.8.1299790922811.JavaMail.tomcat@www.crosswire.org>
Message-ID: <665712706.12.1299832502845.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094#comment-14094 ] 

Martin Denham commented on JS-175:
----------------------------------

I just realised how stupid this request is because you can't find the index of tree elements.

What I really would like to do is find the next/prev key e.g. if on section1/chapter1 then pressing Next takes you to section1/chapter2.  Is there anything in JSword that will help me do that for a TreeKey or do I need to manually navigate the tree?

> indexOf a valid Key in Josephus returns -1
> ------------------------------------------
>
>                 Key: JS-175
>                 URL: http://www.crosswire.org/bugs/browse/JS-175
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> Here is my test:
> 	Book book = getBook("Josephus");
> 	assertNotNull("Josephus not available", book);
> 	
> 	// find a key and print out it's name - this works
> 	final String SECTION_2 = "Section 2";
> 	Key key = book.getKey(SECTION_2);
> 	assertEquals(SECTION_2, key.getName());
> 	
> 	// but we can't get it's index - this returns -1
> 	int keyPos = book.getGlobalKeyList().indexOf(key);
> 	assertFalse("Could not get index of a valid key", -1==keyPos);
> When dealing with a book having TreeKeys the top level Key returned by book.getGlobalKeyList is not a TreeKey but a KeyList which therefore does not automatically search it's children.  So I wonder if SwordGenBook.global could be a TreeKey rather than a ReadOnlyKeyList.
> Maybe the way it works is the way it should work but I am not sure.  Now I realise what is happening I could just call indexOf on each child of the globalKeyList but I think it would be more elegant if globalKeyList.indexOf returned a key from lower down in the tree.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Fri Mar 11 03:18:02 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Fri, 11 Mar 2011 03:18:02 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <257180098.27.1299838682837.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098#comment-14098 ] 

Martin Denham commented on JS-173:
----------------------------------

Hi DM.  Was it just IgnoreTag and XMLUtil that you needed to change or were there other files?  I am trying to get the fix without doing a full check out at this time.

> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Fri Mar 11 06:34:39 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Fri, 11 Mar 2011 06:34:39 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <297194719.1.1299850479916.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100#comment-14100 ] 

DM Smith commented on JS-173:
-----------------------------

I accidentally did the commit w/o a log message. It was revision r2112. Here is the listing:
$ svn log -r r2112
------------------------------------------------------------------------
r2112 | dmsmith | 2011-03-10 20:29:39 -0500 (Thu, 10 Mar 2011) | 1 line
Changed paths:
   M /trunk/jsword/src/main/java/org/crosswire/common/xml/XMLUtil.java
   M /trunk/jsword/src/main/java/org/crosswire/jsword/book/filter/thml/IgnoreTag.java
   M /trunk/jsword/src/main/java/org/crosswire/jsword/book/filter/thml/THMLFilter.java


> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Fri Mar 11 12:55:39 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Fri, 11 Mar 2011 12:55:39 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-173) Error reading GenBook
 (Pilgrim's Progress)
In-Reply-To: <814748655.2.1299624766368.JavaMail.tomcat@www.crosswire.org>
Message-ID: <676949267.2.1299873339081.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101#comment-14101 ] 

Martin Denham commented on JS-173:
----------------------------------

Thanks DM,
That looks like a tricky fix but Pilgrim's Progress works now.
I am adding Gen Books to And Bible at the moment - that is why I am digging around in this area.
Martin

> Error reading GenBook (Pilgrim's Progress)
> ------------------------------------------
>
>                 Key: JS-173
>                 URL: http://www.crosswire.org/bugs/browse/JS-173
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.filter.thml
>    Affects Versions: 1.6.1
>         Environment: Windows and Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I think this is a JSword error, unless I am doing something wrong.  I am getting an Exception when trying to read Pilgrim's Progress and have a simple way to reproduce it.
> Here is my test.  The only custom bit below is my getBook method.  The error occurs on the getSAXEventProvider line
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getKey("THE FIRST STAGE");
> 	BookData data = new BookData(book, key);		
> 	SAXEventProvider osissep = data.getSAXEventProvider();
> Here is the StackTrace:
> org.jdom.IllegalAddException: The Content already has an existing parent "seg"
> 	at org.jdom.ContentList.add(ContentList.java:209)
> 	at org.jdom.ContentList.add(ContentList.java:131)
> 	at org.jdom.ContentList.addAll(ContentList.java:283)
> 	at org.jdom.ContentList.addAll(ContentList.java:253)
> 	at org.jdom.Element.addContent(Element.java:827)
> 	at org.crosswire.jsword.book.filter.thml.IgnoreTag.processContent(IgnoreTag.java:53)
> 	at org.crosswire.jsword.book.filter.thml.CustomHandler.endElement(CustomHandler.java:164)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
> 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
> 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
> 	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> 	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.parse(THMLFilter.java:154)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.cleanParse(THMLFilter.java:109)
> 	at org.crosswire.jsword.book.filter.thml.THMLFilter.toOSIS(THMLFilter.java:70)
> 	at org.crosswire.jsword.book.sword.SwordGenBook.getOsisIterator(SwordGenBook.java:129)
> 	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
> 	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
> 	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
> 	at net.bible.service.sword.SwordApiTest.testReadPilgrimsProgress(SwordApiTest.java:128)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From mjdenham at gmail.com  Fri Mar 11 13:57:25 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Fri, 11 Mar 2011 20:57:25 +0000
Subject: [jsword-devel] Cannot Download files from Xiphos Repo Using
	JSword
In-Reply-To: <AANLkTinVsbhnaogGyVY-Me0qKbrcVmR=tME4Utq+ELD6@mail.gmail.com>
References: <AANLkTinVsbhnaogGyVY-Me0qKbrcVmR=tME4Utq+ELD6@mail.gmail.com>
Message-ID: <AANLkTinOdBg5eyoRB9SzXAqk-6XWOuWLW+Rbt80YjaXT@mail.gmail.com>

I thought I would do a follow up on this.

*Status*
As most of you will already know Sword doesn't use the zips, it uses the
files directly, and that is why Sword can use Xiphos repo without error.
Also, my previous post did not prompt any changes that might allow JSword to
access the Xiphos repo zip files - which is a shame.

At the moment I am implementing Gen Books and wanted to include some of the
Gen Books from Xiphos into the list of available books for users to read
because the Xiphos repo has a nice selection which incidentally includes one
of my recent favourites "The Life and Times of Jesus Christ the Messiah" by
Alfred Edersheim.

*My Attempts*
Well here is how I got on in my attempts.  I managed to download from Xiphos
repo a couple of ways:
1. hack JSword HttpSwordInstaller to force lowercase file name if the repo
being used is Xiphos
2. feed in a conf file with a lower case name/initials
3. use lowercase name if download fails

Methods 1 & 2 seem to work and the first was more seamless from a user's
perspective but the second allowed me to contain the code in And Bible and
avoid another JSword tweak.  The only problem with the second is that a
module's initials are displayed as lowercase until the app is restarted.  If
the user tried to download an index AB wouldn't be able to finf it but
GenBooks don't have indexes at the moment so the problem is avoided.  I
can't think of any other issues and I think I could probably force the
initials to be correct if I needed to.
Method 3 is a variation on method 1 that would continue to work if the names
were ever altered to mixed case.  So in theory it looks good but seems
untidy so I didn't try it.

*Problem Zips in Xiphos*
There are some books like Baxter, SacredMeditations and Shaw that I managed
to download but not expand.  However, I have put enough effort in this area
for now so I just won't show those books in the download list.

If in the future somebody plans to change the case of the file names in the
Xiphos repo I will need some warning!

Regards
Martin

On 14 February 2011 20:52, Martin Denham <mjdenham at gmail.com> wrote:

> I tried downloading from Xiphos tonight but as DM feared there were
> filename case issues because JSword looks for a mixed case name based on the
> first [*name*] line in the .conf file and all the files on ftp.xiphos.orgare lower case.
>
> Here is the problem, using Gill as an example.
>
> JSword reads the module's initials from the first [Gill] line in gill.conf
> Module initials: Gill
>
> Xiphos has filename gill.zip
> Zip file: http://ftp.xiphos.org/sword/zip/gill.zip
>
> JSword HttpSwordInstaller tries to load
> http://ftp.xiphos.org/sword/zip/Gill.zip and throws an error because there
> is no Gill .zip, only a gill.zip.
>
> It would be good to know what Sword does because clearly Sword can read all
> the repositories.
>
> For info the settings I am using in InstallManager.plugin are:
> Installer.4=sword-http,Xiphos,ftp.xiphos.org,/sword/zip,/sword,,,
>
> Regards
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110311/ebc10539/attachment.html>

From jira at crosswire.org  Sat Mar 12 06:12:25 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sat, 12 Mar 2011 06:12:25 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-175) indexOf a valid Key in
 Josephus returns -1
In-Reply-To: <1139788319.8.1299790922811.JavaMail.tomcat@www.crosswire.org>
Message-ID: <2069117987.1.1299935545878.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110#comment-14110 ] 

DM Smith commented on JS-175:
-----------------------------

bq. What I really would like to do is find the next/prev key e.g. if on section1/chapter1 then pressing Next takes you to section1/chapter2. Is there anything in JSword that will help me do that for a TreeKey or do I need to manually navigate the tree?

One of the things about JSword is that it does not have a proper notion of previous/next. It has all kinds of iterators, but those have no notion of previous. key.get(n+1) and key.get(n-1) work for KeyLists but not TreeKeys.

It's not clear what next really means? I.e. is it depth-first or breadth first. It sounds that if you are on a second level node of 8 levels that next should stay on the same level but return the next sibling. If on the last sibling, then next() should be done.

If this is the case, you are iterating over the children of the parent. parent.get(n) will get the n-th child. You can write next sibling as:
{code}
Key nextSibling(Key key) throws IndexOutOfBoundsException {
   Key parent = key.getParent();
   int currentIndex = parent.indexOf(key);
   return parent.get(currentIndex + 1);
}

{code}
JSword's KeyIterator does a depth-first iterating of TreeKey. But it doesn't have previous.

If you mean that next means get next leaf, then I'd dump the leaves into a List. I'd try something like:
final DefaultKeyList leafList = new DefaultKeyList();
KeyUtil.visit(key, new DefaultKeyVisitor() {
 @Override
 public void visitLeaf(Key k) {
    leafList.add(k);
 }
});

Note, such a call gets all the keys below the TreeKey. If this is useful, we can add this to JSword.




> indexOf a valid Key in Josephus returns -1
> ------------------------------------------
>
>                 Key: JS-175
>                 URL: http://www.crosswire.org/bugs/browse/JS-175
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> Here is my test:
> 	Book book = getBook("Josephus");
> 	assertNotNull("Josephus not available", book);
> 	
> 	// find a key and print out it's name - this works
> 	final String SECTION_2 = "Section 2";
> 	Key key = book.getKey(SECTION_2);
> 	assertEquals(SECTION_2, key.getName());
> 	
> 	// but we can't get it's index - this returns -1
> 	int keyPos = book.getGlobalKeyList().indexOf(key);
> 	assertFalse("Could not get index of a valid key", -1==keyPos);
> When dealing with a book having TreeKeys the top level Key returned by book.getGlobalKeyList is not a TreeKey but a KeyList which therefore does not automatically search it's children.  So I wonder if SwordGenBook.global could be a TreeKey rather than a ReadOnlyKeyList.
> Maybe the way it works is the way it should work but I am not sure.  Now I realise what is happening I could just call indexOf on each child of the globalKeyList but I think it would be more elegant if globalKeyList.indexOf returned a key from lower down in the tree.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 06:19:25 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sat, 12 Mar 2011 06:19:25 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-176) Incorrect resource text
 causing missing Missing Resource error
In-Reply-To: <564775860.9.1299795422827.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1630205750.3.1299935965343.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111#comment-14111 ] 

DM Smith commented on JS-176:
-----------------------------

I checked in changes. See the Subversion Commits tab for the files.

Basically, I removed "given" from the strings everywhere. I also cleaned up  the strings to be consistent with each other.

> Incorrect resource text causing missing Missing Resource error
> --------------------------------------------------------------
>
>                 Key: JS-176
>                 URL: http://www.crosswire.org/bugs/browse/JS-176
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.common.util
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> IOUtil and NetUtil both contain messages like "The given URL {0} could not be created ... as a [file|directory]"
> but UserMsg.properties contains "The URL {0} could not be created ... as a [file|directory]" without the word 'given'
> So the word 'given' is missing from 2 messages in UserMsg.properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 06:27:25 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sat, 12 Mar 2011 06:27:25 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-174) Infinite recursion
 getting osis id for a TreeKey
In-Reply-To: <1966455976.0.1299672515582.JavaMail.tomcat@www.crosswire.org>
Message-ID: <803050129.5.1299936445609.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112#comment-14112 ] 

DM Smith commented on JS-174:
-----------------------------

This is a silly bug in unused code.
The KeyVisitor for getName() getOsisId() and getOsisRef() all call key.getXXX().

On Keys other than TreeKey, it will work just fine. But on a TreeKey it will recurse.

One of the things that this points out is that we need more robust JUnit test cases.

How were you hoping to use the results of the call?

> Infinite recursion getting osis id for a TreeKey
> ------------------------------------------------
>
>                 Key: JS-174
>                 URL: http://www.crosswire.org/bugs/browse/JS-174
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I am not sure if it makes sense to get an osis id for a TreeKey treeKey.getName works fine but when I tried treeKey.getOsisID it failed with some sort of infinite recursion error.  I wonder if the new java 5 for loop in KeyUtil.visit is causing a problem.
> Here is my test:
> 	Book book = getBook("Pilgrim");  // Bunyan's Pilgrim's Progress
> 	Key key = book.getKey("THE FIRST STAGE");
> 	key.getOsisID(); // error occurs here
> Here is the top of the stack trace:
> java.lang.StackOverflowError
> 	at java.util.Stack.peek(Stack.java:86)
> 	at org.crosswire.jsword.passage.KeyIterator.prepare(KeyIterator.java:49)
> 	at org.crosswire.jsword.passage.KeyIterator.hasNext(KeyIterator.java:63)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:68)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:36)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:50)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> // the calls to .visit go on and on...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 07:27:24 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Sat, 12 Mar 2011 07:27:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-174) Infinite recursion
 getting osis id for a TreeKey
In-Reply-To: <1966455976.0.1299672515582.JavaMail.tomcat@www.crosswire.org>
Message-ID: <552429161.6.1299940044718.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113#comment-14113 ] 

Martin Denham commented on JS-174:
----------------------------------

I don't actually use treeKey.getOsisID now.  I use treeKey.getName instead but at the start of gen book coding I wasn't sure which ID to use in order to find a particular treeKey again so I tried both name and osisId.

I raised the bug because I saw the error but it is not affecting me.

> Infinite recursion getting osis id for a TreeKey
> ------------------------------------------------
>
>                 Key: JS-174
>                 URL: http://www.crosswire.org/bugs/browse/JS-174
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> I am not sure if it makes sense to get an osis id for a TreeKey treeKey.getName works fine but when I tried treeKey.getOsisID it failed with some sort of infinite recursion error.  I wonder if the new java 5 for loop in KeyUtil.visit is causing a problem.
> Here is my test:
> 	Book book = getBook("Pilgrim");  // Bunyan's Pilgrim's Progress
> 	Key key = book.getKey("THE FIRST STAGE");
> 	key.getOsisID(); // error occurs here
> Here is the top of the stack trace:
> java.lang.StackOverflowError
> 	at java.util.Stack.peek(Stack.java:86)
> 	at org.crosswire.jsword.passage.KeyIterator.prepare(KeyIterator.java:49)
> 	at org.crosswire.jsword.passage.KeyIterator.hasNext(KeyIterator.java:63)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:68)
> 	at org.crosswire.jsword.passage.KeyIterator.next(KeyIterator.java:36)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:50)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> 	at org.crosswire.jsword.passage.KeyUtil.visit(KeyUtil.java:53)
> // the calls to .visit go on and on...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 07:59:24 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Sat, 12 Mar 2011 07:59:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-177) Need a null check in
 GenBookBackend.getRawText
Message-ID: <1023079962.7.1299941964671.JavaMail.tomcat@www.crosswire.org>

Need a null check in GenBookBackend.getRawText
----------------------------------------------

                 Key: JS-177
                 URL: http://www.crosswire.org/bugs/browse/JS-177
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.book.sword
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


A null check is required in the following code in GenBookBackend.getRawText because find can return a null meaning that node, when used on the next line could be null:

            DataPolice.setKey(key);
            TreeNode node = find(key);
            byte[] userData = node.getUserData();

            // Some entries may be empty.
            if (userData.length == 8) {

Here is a suggested fix but I don't know if you should return a null or an empty string in this scenario:

            DataPolice.setKey(key);
            TreeNode node = find(key);
            
            // Is there an entry?
            if (node == null) {
                return "";
            }

            byte[] userData = node.getUserData();

Here is a simple test:
	Book book = getBook("Pilgrim");
	Key key = book.getGlobalKeyList();
	String rawText = book.getRawText(key);


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 08:54:24 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Sat, 12 Mar 2011 08:54:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-175) indexOf a valid Key in
 Josephus returns -1
In-Reply-To: <1139788319.8.1299790922811.JavaMail.tomcat@www.crosswire.org>
Message-ID: <760802247.8.1299945264709.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114#comment-14114 ] 

Martin Denham commented on JS-175:
----------------------------------

I like your idea of flattening out the tree and using that for indexes.  My current code tries to traverse the tree at each call to prev/next and it is a bit messy.  However, I was experimenting a little with your method and suddenly realised that getGlobalKeyList is doing almost that except that it includes non-leaf nodes.  I was confused because when I call getGlobalKeyList.getChildCount I was getting a very small number:
   genBook.getGlobalKeyList returns all the keys, flattened and in the correct order. getCardinality reflects all keys
   genBook.getGlobalKeyList.getChildCount/get(child)/indexOf/contains only use one level of keys

You can see that in:
	Book book = getBook("Pilgrim");
	Key globalKeyList = book.getGlobalKeyList();
	assertEquals("Incorrect number of keys in master list", 29, globalKeyList.getCardinality());
	assertEquals("Incorrect number of top level keys", 6, globalKeyList.getChildCount());


I thought I had to navigate a Gen Book as a tree (like BD or Xiphos) but I think I will try showing all keys returned by getGlobalKeyList in one long list.  If a Key has no content then it seems to use the Key Name as content but almost all keys I have tested have content.

> indexOf a valid Key in Josephus returns -1
> ------------------------------------------
>
>                 Key: JS-175
>                 URL: http://www.crosswire.org/bugs/browse/JS-175
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.passage
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> Here is my test:
> 	Book book = getBook("Josephus");
> 	assertNotNull("Josephus not available", book);
> 	
> 	// find a key and print out it's name - this works
> 	final String SECTION_2 = "Section 2";
> 	Key key = book.getKey(SECTION_2);
> 	assertEquals(SECTION_2, key.getName());
> 	
> 	// but we can't get it's index - this returns -1
> 	int keyPos = book.getGlobalKeyList().indexOf(key);
> 	assertFalse("Could not get index of a valid key", -1==keyPos);
> When dealing with a book having TreeKeys the top level Key returned by book.getGlobalKeyList is not a TreeKey but a KeyList which therefore does not automatically search it's children.  So I wonder if SwordGenBook.global could be a TreeKey rather than a ReadOnlyKeyList.
> Maybe the way it works is the way it should work but I am not sure.  Now I realise what is happening I could just call indexOf on each child of the globalKeyList but I think it would be more elegant if globalKeyList.indexOf returned a key from lower down in the tree.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From refdoc at gmx.net  Sat Mar 12 08:54:10 2011
From: refdoc at gmx.net (Peter von Kaehne)
Date: Sat, 12 Mar 2011 15:54:10 +0000
Subject: [jsword-devel] Cannot Download files from Xiphos Repo
	Using	JSword
In-Reply-To: <AANLkTinOdBg5eyoRB9SzXAqk-6XWOuWLW+Rbt80YjaXT@mail.gmail.com>
References: <AANLkTinVsbhnaogGyVY-Me0qKbrcVmR=tME4Utq+ELD6@mail.gmail.com>
 <AANLkTinOdBg5eyoRB9SzXAqk-6XWOuWLW+Rbt80YjaXT@mail.gmail.com>
Message-ID: <4D7B9722.7050900@gmx.net>


> 
>     It would be good to know what Sword does because clearly Sword can
>     read all the repositories.

Is it not simply using the PATH from the config file? When I make
modules I certainly do not care much about identity of [Name] and PATH.

If you rely on [Name] to find the module, chances are that you will
fail, but if you use PATH you must succeed - otherwise the module is out
of order anyway.

Peter


From dmsmith at crosswire.org  Sat Mar 12 09:08:23 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Sat, 12 Mar 2011 11:08:23 -0500
Subject: [jsword-devel] Cannot Download files from Xiphos Repo
	Using	JSword
In-Reply-To: <4D7B9722.7050900@gmx.net>
References: <AANLkTinVsbhnaogGyVY-Me0qKbrcVmR=tME4Utq+ELD6@mail.gmail.com>
 <AANLkTinOdBg5eyoRB9SzXAqk-6XWOuWLW+Rbt80YjaXT@mail.gmail.com>
 <4D7B9722.7050900@gmx.net>
Message-ID: <CB888C0C-A3E5-409C-BA3C-DCD4CEE03F23@crosswire.org>

On Mar 12, 2011, at 10:54 AM, Peter von Kaehne wrote:

> 
>> 
>>    It would be good to know what Sword does because clearly Sword can
>>    read all the repositories.
> 
> Is it not simply using the PATH from the config file? When I make
> modules I certainly do not care much about identity of [Name] and PATH.

Path is not at all helpful in determining the name of the zip file.

> 
> If you rely on [Name] to find the module, chances are that you will
> fail, but if you use PATH you must succeed - otherwise the module is out
> of order anyway.
We rely on [Name] to determine the name of the zip file. We also use it as the unique key within a repository, and within the collection of installed books. Other than that, it is used in diagnostic messages.

Path is used to get the files for the locally installed module. It is not used in downloading the zip file. It is not useful for that.

I will be adding back in the FTP methodology and use it as a fallback for failed download of the zip.

This will solve the Xiphos repository zip file name problem.

In Him,
DM

From jira at crosswire.org  Sat Mar 12 09:32:24 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Sat, 12 Mar 2011 09:32:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-178) Keys of 'Westminster
 Confession & Catechisms' Gen Book are in the wrong order
Message-ID: <1005846663.9.1299947544707.JavaMail.tomcat@www.crosswire.org>

Keys of 'Westminster Confession & Catechisms' Gen Book are in the wrong order
-----------------------------------------------------------------------------

                 Key: JS-178
                 URL: http://www.crosswire.org/bugs/browse/JS-178
             Project: JSword
          Issue Type: Bug
            Reporter: Martin Denham
            Assignee: DM Smith


This probably is a module error rather than JSword but I don't know who to inform of that.

The order is alphabetic and the Roman numerals like IX come before V.

Here is part of the list:

Chapter I
Chapter II
Chapter III
Chapter IV
Chapter IX
Chapter V
Chapter VI
Chapter VII
Chapter VIII
Chapter X
Chapter XI

Here is how I tested it:
	Book book = getBook("Westminster");
	Key keyList = book.getGlobalKeyList();
	
	System.out.println("Global key list");
	for (Key key : keyList) {
		System.out.println(key.getName());
	}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From refdoc at gmx.net  Sat Mar 12 09:41:49 2011
From: refdoc at gmx.net (Peter von Kaehne)
Date: Sat, 12 Mar 2011 16:41:49 +0000
Subject: [jsword-devel] Cannot Download files from Xiphos
	Repo	Using	JSword
In-Reply-To: <CB888C0C-A3E5-409C-BA3C-DCD4CEE03F23@crosswire.org>
References: <AANLkTinVsbhnaogGyVY-Me0qKbrcVmR=tME4Utq+ELD6@mail.gmail.com>
 <AANLkTinOdBg5eyoRB9SzXAqk-6XWOuWLW+Rbt80YjaXT@mail.gmail.com>
 <4D7B9722.7050900@gmx.net>
 <CB888C0C-A3E5-409C-BA3C-DCD4CEE03F23@crosswire.org>
Message-ID: <4D7BA24D.2090203@gmx.net>

On 12/03/11 16:08, DM Smith wrote:
> On Mar 12, 2011, at 10:54 AM, Peter von Kaehne wrote:
> 
>> Is it not simply using the PATH from the config file? When I make
>> modules I certainly do not care much about identity of [Name] and PATH.
> 
> Path is not at all helpful in determining the name of the zip file.

I appreciate this. But I do think PATH is used to find the files in the
unzipped modules for download via ftp.

And what I am trying to say - the standards as described in the Wiki etc
are solely concerned with sword's download method. I certainly never
ever considered the problem Martin described.

Anyway, I am glad that you add the ftp method back in.

Peter


From jira at crosswire.org  Sat Mar 12 14:36:26 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sat, 12 Mar 2011 14:36:26 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-177) Need a null check in
 GenBookBackend.getRawText
In-Reply-To: <1023079962.7.1299941964671.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1253771948.14.1299965786003.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116#comment-14116 ] 

DM Smith commented on JS-177:
-----------------------------

Just checked in a change. It no longer throws an NPE but now throws a BookException.

> Need a null check in GenBookBackend.getRawText
> ----------------------------------------------
>
>                 Key: JS-177
>                 URL: http://www.crosswire.org/bugs/browse/JS-177
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.sword
>    Affects Versions: 1.6.1
>         Environment: All
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> A null check is required in the following code in GenBookBackend.getRawText because find can return a null meaning that node, when used on the next line could be null:
>             DataPolice.setKey(key);
>             TreeNode node = find(key);
>             byte[] userData = node.getUserData();
>             // Some entries may be empty.
>             if (userData.length == 8) {
> Here is a suggested fix but I don't know if you should return a null or an empty string in this scenario:
>             DataPolice.setKey(key);
>             TreeNode node = find(key);
>             
>             // Is there an entry?
>             if (node == null) {
>                 return "";
>             }
>             byte[] userData = node.getUserData();
> Here is a simple test:
> 	Book book = getBook("Pilgrim");
> 	Key key = book.getGlobalKeyList();
> 	String rawText = book.getRawText(key);

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sat Mar 12 14:42:26 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sat, 12 Mar 2011 14:42:26 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-154) BufferedReader should use
 an explicit buffer size.
In-Reply-To: <1608934975.15.1293925874902.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1665673266.16.1299966146055.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117#comment-14117 ] 

DM Smith commented on JS-154:
-----------------------------

I'll set it back and let you figure out the size that you'd like to use.

> BufferedReader should use an explicit buffer size.
> --------------------------------------------------
>
>                 Key: JS-154
>                 URL: http://www.crosswire.org/bugs/browse/JS-154
>             Project: JSword
>          Issue Type: Sub-task
>          Components: o.c.common.util
>    Affects Versions: 1.6
>         Environment: Android.
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> When not specified, a BufferedReader uses an undefined buffer size. The javadoc claims that the size is appropriate for most uses. Android gives a warning message indicating that a specific size should be used.
> The default size in Sun's Java is 8192. Until we have better info, use this to quiet Android's vm.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sun Mar 13 19:28:31 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sun, 13 Mar 2011 19:28:31 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-179) Have the full
 iso639.properties be optional
Message-ID: <1921705887.1.1300069711086.JavaMail.tomcat@www.crosswire.org>

Have the full iso639.properties be optional
-------------------------------------------

                 Key: JS-179
                 URL: http://www.crosswire.org/bugs/browse/JS-179
             Project: JSword
          Issue Type: Sub-task
          Components: o.c.common.util
            Reporter: DM Smith
            Assignee: DM Smith


The iso639.properties has the full list of language names. It slows startup significantly.

Move iso639.properties to a new name, e.g. iso639full.properties. Add it for lookup only if language has not been found in the shorter iso639.properties and explicitly requested. Otherwise give the current answer for an unknown language.

Since iso639.properties is renamed, a default needs to be established.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Sun Mar 13 19:37:31 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Sun, 13 Mar 2011 19:37:31 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-180) Have iso639.properties the
 default be translated in each language
Message-ID: <1118724491.3.1300070251069.JavaMail.tomcat@www.crosswire.org>

Have iso639.properties the default be translated in each language
-----------------------------------------------------------------

                 Key: JS-180
                 URL: http://www.crosswire.org/bugs/browse/JS-180
             Project: JSword
          Issue Type: Improvement
          Components: o.c.common.util
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


iso639.properties is in English. It'd be better for it to have each language be written in that language.

See: http://crosswire.org/wiki/Localized_Language_Names.

The issue is that of font support.

Alternatively, have it be in English, but add iso639localized.properties and make that optional.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From scribe at crosswire.org  Mon Mar 14 00:52:40 2011
From: scribe at crosswire.org (Troy A. Griffitts)
Date: Mon, 14 Mar 2011 07:52:40 +0000
Subject: [jsword-devel] [JIRA] Created: (JS-180) Have iso639.properties
 the default be translated in each language
In-Reply-To: <1118724491.3.1300070251069.JavaMail.tomcat@www.crosswire.org>
References: <1118724491.3.1300070251069.JavaMail.tomcat@www.crosswire.org>
Message-ID: <4D7DC948.60605@crosswire.org>

  Have a look at SWORD's data.  It might be useful:

http://crosswire.org/svn/sword/trunk/locales.d/locales.conf



On 3/14/2011 2:37 AM, DM Smith (JIRA) wrote:
> Have iso639.properties the default be translated in each language
> -----------------------------------------------------------------
>
>                   Key: JS-180
>                   URL: http://www.crosswire.org/bugs/browse/JS-180
>               Project: JSword
>            Issue Type: Improvement
>            Components: o.c.common.util
>      Affects Versions: 1.6
>              Reporter: DM Smith
>              Assignee: DM Smith
>               Fix For: 1.6.1
>
>
> iso639.properties is in English. It'd be better for it to have each language be written in that language.
>
> See: http://crosswire.org/wiki/Localized_Language_Names.
>
> The issue is that of font support.
>
> Alternatively, have it be in English, but add iso639localized.properties and make that optional.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel



From dmsmith at crosswire.org  Mon Mar 14 05:26:05 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Mon, 14 Mar 2011 08:26:05 -0400
Subject: [jsword-devel] [JIRA] Created: (JS-180) Have iso639.properties
	the default be translated in each language
In-Reply-To: <4D7DC948.60605@crosswire.org>
References: <1118724491.3.1300070251069.JavaMail.tomcat@www.crosswire.org>
 <4D7DC948.60605@crosswire.org>
Message-ID: <8DD5D8B2-9104-4A29-B75B-BED59E627A47@crosswire.org>

Troy, Thanks! I'm merging it in. I was missing a few for which I have no fonts on a Mac.

I noticed a bug in the Azerbijani: The script variants Arab and Cyrl are flipped.

In Him,
DM


On Mar 14, 2011, at 3:52 AM, Troy A. Griffitts wrote:

> Have a look at SWORD's data.  It might be useful:
> 
> http://crosswire.org/svn/sword/trunk/locales.d/locales.conf
> 
> 
> 
> On 3/14/2011 2:37 AM, DM Smith (JIRA) wrote:
>> Have iso639.properties the default be translated in each language
>> -----------------------------------------------------------------
>> 
>>                  Key: JS-180
>>                  URL: http://www.crosswire.org/bugs/browse/JS-180
>>              Project: JSword
>>           Issue Type: Improvement
>>           Components: o.c.common.util
>>     Affects Versions: 1.6
>>             Reporter: DM Smith
>>             Assignee: DM Smith
>>              Fix For: 1.6.1
>> 
>> 
>> iso639.properties is in English. It'd be better for it to have each language be written in that language.
>> 
>> See: http://crosswire.org/wiki/Localized_Language_Names.
>> 
>> The issue is that of font support.
>> 
>> Alternatively, have it be in English, but add iso639localized.properties and make that optional.
>> 
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>> 
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel



From jira at crosswire.org  Tue Mar 15 06:51:36 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Tue, 15 Mar 2011 06:51:36 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-181) Merge Bible Desktop Bible
 sections into JSword
Message-ID: <1422405017.1.1300197096332.JavaMail.tomcat@www.crosswire.org>

Merge Bible Desktop Bible sections into JSword
----------------------------------------------

                 Key: JS-181
                 URL: http://www.crosswire.org/bugs/browse/JS-181
             Project: JSword
          Issue Type: Improvement
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


Bible Desktop has a dropdown of sections. These overlap those of o.c.j.versification.SectionNames. They should be merged into SectionNames.

SectionNames currently has non-overlapping sections. With the merge it will have overlapping sections. E.g. The Whole Bible (or The Bible), OT, NT, Prophecy, Letters to the People (aka pauline), Letters from the People, overlap with the ones already present.

The API for SectionNames should change to an Enum. Please comment on the impact to your usage.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Tue Mar 15 21:48:36 2011
From: jira at crosswire.org (Tonny Kohar (JIRA))
Date: Tue, 15 Mar 2011 21:48:36 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-181) Merge Bible Desktop Bible
 sections into JSword
In-Reply-To: <1422405017.1.1300197096332.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1219610112.3.1300250916153.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122#comment-14122 ] 

Tonny Kohar commented on JS-181:
--------------------------------

Yes, fine with me (Alkitab Bible Study)

> Merge Bible Desktop Bible sections into JSword
> ----------------------------------------------
>
>                 Key: JS-181
>                 URL: http://www.crosswire.org/bugs/browse/JS-181
>             Project: JSword
>          Issue Type: Improvement
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> Bible Desktop has a dropdown of sections. These overlap those of o.c.j.versification.SectionNames. They should be merged into SectionNames.
> SectionNames currently has non-overlapping sections. With the merge it will have overlapping sections. E.g. The Whole Bible (or The Bible), OT, NT, Prophecy, Letters to the People (aka pauline), Letters from the People, overlap with the ones already present.
> The API for SectionNames should change to an Enum. Please comment on the impact to your usage.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From mjdenham at gmail.com  Wed Mar 16 14:47:21 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Wed, 16 Mar 2011 21:47:21 +0000
Subject: [jsword-devel] Confused that GenBookBackend denies containing empty
	keys
Message-ID: <AANLkTikXJ+sX+J8oHtbhrQGyy2_TD=ocXHVbn5iBEwMr@mail.gmail.com>

Hi,

I am a bit confused by GenBookBackend.contains(key).  Here is some test
code, btw HodgeSysTheo is from Xiphos repo:

Book book = getBook("HodgeSysTheo");
Key volume1Key = book.getKey("Volume I");  // that is a capital I (*eye*)
not a number one on the end
assertNotNull("Vol 1 not found", volume1Key);
if (!book.contains(volume1Key)) {
System.out.println("Book does not contain a valid key");
}

So you can see that I am getting a key from a GenBook but when I check to
see if the same GenBook contains the key then I get false if the key does
not contain anything.  Maybe this is correct but I thought I would ask just
in case it is a bug.

The bit of code that implements contains() is

            TreeNode node = find(key);   // this returns true
            // Is there an entry?
            if (node == null) {
                return false;
            }

            // Is it non-empty?
            byte[] userData = node.getUserData();

            // Some entries may be empty.
            return userData.length == 8;   // this is false for the test key
being used i.e. 'Volume I'

Either way I can make And Bible work but I just want to check the above is
correct because it surprised me a bit.

Thanks
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110316/fd024109/attachment.html>

From jira at crosswire.org  Wed Mar 16 15:12:24 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Wed, 16 Mar 2011 15:12:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-181) Merge Bible Desktop Bible
 sections into JSword
In-Reply-To: <1422405017.1.1300197096332.JavaMail.tomcat@www.crosswire.org>
Message-ID: <781957952.1.1300313544646.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130#comment-14130 ] 

Martin Denham commented on JS-181:
----------------------------------

And Bible used to use Sections a lot to structure books of the bible for navigation but recently AB switched to a grid and some people have suggested removing the old navigation method so you don't need to worry about AB.

> Merge Bible Desktop Bible sections into JSword
> ----------------------------------------------
>
>                 Key: JS-181
>                 URL: http://www.crosswire.org/bugs/browse/JS-181
>             Project: JSword
>          Issue Type: Improvement
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> Bible Desktop has a dropdown of sections. These overlap those of o.c.j.versification.SectionNames. They should be merged into SectionNames.
> SectionNames currently has non-overlapping sections. With the merge it will have overlapping sections. E.g. The Whole Bible (or The Bible), OT, NT, Prophecy, Letters to the People (aka pauline), Letters from the People, overlap with the ones already present.
> The API for SectionNames should change to an Enum. Please comment on the impact to your usage.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From dmsmith at crosswire.org  Wed Mar 16 15:33:04 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Wed, 16 Mar 2011 18:33:04 -0400
Subject: [jsword-devel] Confused that GenBookBackend denies containing
	empty keys
In-Reply-To: <AANLkTikXJ+sX+J8oHtbhrQGyy2_TD=ocXHVbn5iBEwMr@mail.gmail.com>
References: <AANLkTikXJ+sX+J8oHtbhrQGyy2_TD=ocXHVbn5iBEwMr@mail.gmail.com>
Message-ID: <8FB25E40-3BE5-41F3-BE0E-B61E5C9C73CD@crosswire.org>


On Mar 16, 2011, at 5:47 PM, Martin Denham wrote:

> Hi,
> 
> I am a bit confused by GenBookBackend.contains(key).  Here is some test code, btw HodgeSysTheo is from Xiphos repo:
> 
> 		Book book = getBook("HodgeSysTheo");
> 		Key volume1Key = book.getKey("Volume I");  // that is a capital I (eye) not a number one on the end
> 		assertNotNull("Vol 1 not found", volume1Key);
> 		if (!book.contains(volume1Key)) {
> 			System.out.println("Book does not contain a valid key");
> 		}

The TreeNode contains no data. For that reason it returns false.

But, I don't think that is right. If we want that behavior then we should have a different method for that (or a second argument to this one, e.g. boolean withContent DEFAULT false.

I'll have to look to see if we have any code that depends upon that behavior. (e.g. building a key list of that with content).

> 
> So you can see that I am getting a key from a GenBook but when I check to see if the same GenBook contains the key then I get false if the key does not contain anything.  Maybe this is correct but I thought I would ask just in case it is a bug.
> 
> The bit of code that implements contains() is
> 
>             TreeNode node = find(key);   // this returns true
It should have just return here with:
return node != null;

>             // Is there an entry?
>             if (node == null) {
>                 return false;
>             }


> 
>             // Is it non-empty?
>             byte[] userData = node.getUserData();
> 
>             // Some entries may be empty.
>             return userData.length == 8;   // this is false for the test key being used i.e. 'Volume I'
> 
> Either way I can make And Bible work but I just want to check the above is correct because it surprised me a bit.
> 
> Thanks
> Martin
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110316/3802d57d/attachment.html>

From jira at crosswire.org  Wed Mar 16 19:35:24 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 16 Mar 2011 19:35:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-182) GenBookBackend problem in
	contains(Key)
Message-ID: <1138407766.3.1300329324598.JavaMail.tomcat@www.crosswire.org>

GenBookBackend problem in contains(Key)
---------------------------------------

                 Key: JS-182
                 URL: http://www.crosswire.org/bugs/browse/JS-182
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.book.sword
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


GenBookBackend's boolean contains(Key) does not return true for every key returned by Key readIndex().

The problem is that some keys (interior nodes) have no text associated with them. The method contains(Key) tests to see if there is data associated with the key. It should just test either
* that it is a valid node or
* that it is an interior node with children or a leaf node with content.
Either way a node that returns false should not be in the result of readIndex.

Given that getRawText(Key) will return "" for such keys, I think the first way is most reasonable.

Looking at the code, I can't see where the current behavior is relied upon.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Wed Mar 16 19:39:24 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Wed, 16 Mar 2011 19:39:24 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-182) GenBookBackend problem in
	contains(Key)
In-Reply-To: <1138407766.3.1300329324598.JavaMail.tomcat@www.crosswire.org>
Message-ID: <319213279.5.1300329564583.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131#comment-14131 ] 

DM Smith commented on JS-182:
-----------------------------

Martin, Thanks for the report. I have checked in the change. Let me know if it works for you.

> GenBookBackend problem in contains(Key)
> ---------------------------------------
>
>                 Key: JS-182
>                 URL: http://www.crosswire.org/bugs/browse/JS-182
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.sword
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> GenBookBackend's boolean contains(Key) does not return true for every key returned by Key readIndex().
> The problem is that some keys (interior nodes) have no text associated with them. The method contains(Key) tests to see if there is data associated with the key. It should just test either
> * that it is a valid node or
> * that it is an interior node with children or a leaf node with content.
> Either way a node that returns false should not be in the result of readIndex.
> Given that getRawText(Key) will return "" for such keys, I think the first way is most reasonable.
> Looking at the code, I can't see where the current behavior is relied upon.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Thu Mar 17 05:35:16 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Thu, 17 Mar 2011 05:35:16 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-182) GenBookBackend problem in
	contains(Key)
In-Reply-To: <1138407766.3.1300329324598.JavaMail.tomcat@www.crosswire.org>
Message-ID: <406285272.1.1300365316060.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140#comment-14140 ] 

DM Smith commented on JS-182:
-----------------------------

The way it was written was consistent with how the backend for a Bible was written. For Bibles a module may have empty spots in the index for a verse. For example, a NT with only Matt will only have valid Matt verses but will have entries in the index for every other verse in the NT versification. Those won't point to anywhere valid. The check there is first to see if the index entry makes sense and second to see if it points to something that has content.

Given that the GenBookBackend is also used for Bibles with TreeKey, this might be a concern. (None are released so far, and only are experimental.) Contains(key) should return false for Bibles when the content is empty.

> GenBookBackend problem in contains(Key)
> ---------------------------------------
>
>                 Key: JS-182
>                 URL: http://www.crosswire.org/bugs/browse/JS-182
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.jsword.book.sword
>    Affects Versions: 1.6
>            Reporter: DM Smith
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> GenBookBackend's boolean contains(Key) does not return true for every key returned by Key readIndex().
> The problem is that some keys (interior nodes) have no text associated with them. The method contains(Key) tests to see if there is data associated with the key. It should just test either
> * that it is a valid node or
> * that it is an interior node with children or a leaf node with content.
> Either way a node that returns false should not be in the result of readIndex.
> Given that getRawText(Key) will return "" for such keys, I think the first way is most reasonable.
> Looking at the code, I can't see where the current behavior is relied upon.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira at crosswire.org  Fri Mar 18 11:17:55 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Fri, 18 Mar 2011 11:17:55 -0700 (MST)
Subject: [jsword-devel] [JIRA] Commented: (JS-158) Appropriate default
 logging level for performance
In-Reply-To: <1779898083.3.1295478803232.JavaMail.tomcat@www.crosswire.org>
Message-ID: <1497549854.0.1300472275634.JavaMail.tomcat@www.crosswire.org>


    [ http://www.crosswire.org/bugs/browse/JS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160#comment-14160 ] 

Martin Denham commented on JS-158:
----------------------------------

I just noticed that the default logging level in log4j.properties is also a bit too fine
   log4j.rootLogger=DEBUG, A1
It isn't affecting me because apparently Android must be using the jdk logger but I thought I would point it out.

> Appropriate default logging level for performance
> -------------------------------------------------
>
>                 Key: JS-158
>                 URL: http://www.crosswire.org/bugs/browse/JS-158
>             Project: JSword
>          Issue Type: Bug
>          Components: o.c.common.util
>    Affects Versions: 1.6
>         Environment: Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>             Fix For: 1.6.1
>
>
> The default logging level in jsword/src/main/resources/CWLogging.properties is:
> .level=FINEST
> Unfortunately this can cause libraries like HttpComponents to produce a lot of logging and have performance issues like slow downloads.  Therefore this default logging level should be set higher and lowered explicitly for certain modules as required.  Overriding logging level for each library would be laborious and error prone.
> I have experimented a little with And Bible and discovered that even INFO has a noticeable affect on download time (40 secs for esv) whereas WARNING seems to be a good default (the first level of messages you really need to look at) and also have no noticeable affect on download (<30 secs for esv).  The starting point of FINEST resulted in a 4 minute download time for esv.
> So can I suggest the setting is changed to:
> .level=WARNING

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


From dmsmith at crosswire.org  Sat Mar 19 05:53:16 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Sat, 19 Mar 2011 08:53:16 -0400
Subject: [jsword-devel] Jira upgrade today
Message-ID: <B8D33D63-8F98-4451-83F1-4F94AC35BEC4@crosswire.org>

I'll be upgrading Jira today. It may be down intermittently during the day. For the first time there is an upgrade-in-place capability. This should minimize downtime.

In Him,
	DM Smith

From dmsmith at crosswire.org  Sat Mar 19 15:37:11 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Sat, 19 Mar 2011 18:37:11 -0400
Subject: [jsword-devel] Jira upgrade today
In-Reply-To: <B8D33D63-8F98-4451-83F1-4F94AC35BEC4@crosswire.org>
References: <B8D33D63-8F98-4451-83F1-4F94AC35BEC4@crosswire.org>
Message-ID: <DBE1D193-1057-41C8-918F-49E2C4826A49@crosswire.org>

Jira is back up and running. The mercurial plugin had to be removed as it was not compatible.

You may have noticed some disruption as I had to bounce the web server and tomcat a few times.

In Him,
	DM

On Mar 19, 2011, at 8:53 AM, DM Smith wrote:

> I'll be upgrading Jira today. It may be down intermittently during the day. For the first time there is an upgrade-in-place capability. This should minimize downtime.
> 
> In Him,
> 	DM Smith
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel



From mjdenham at gmail.com  Mon Mar 21 13:06:52 2011
From: mjdenham at gmail.com (Martin Denham)
Date: Mon, 21 Mar 2011 20:06:52 +0000
Subject: [jsword-devel] Comparison of TreeKeys can lead to false positives
Message-ID: <AANLkTikVpDrnqxhBTNtMq2=ny5i73wKfg+-ag4c6VviP@mail.gmail.com>

Hi,

Some Books like Pilgrim's Progress and Edersheim have keys with identical
names but different parents.

Here is an example from Pilgrims Progress:
   Part I/The First Stage
   Part II/The First Stage

So if I have a key1='The First Stage' (in Part II) and I go through a list
of keys looking for a key that equals key1 I will arrive at the wrong key.

I am currently changing my code so that if a TreeKey has a parent I also
compare parents but I was wondering if you think the KeyTree equals method
in JSword should be extended to check parents.

If the above isn't clear I can create a simple junit so show the problem
because I may possibly be taking the wrong approach.

Regards
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110321/e53f7e24/attachment.html>

From dmsmith at crosswire.org  Mon Mar 21 13:10:17 2011
From: dmsmith at crosswire.org (DM Smith)
Date: Mon, 21 Mar 2011 16:10:17 -0400
Subject: [jsword-devel] Comparison of TreeKeys can lead to false
	positives
In-Reply-To: <AANLkTikVpDrnqxhBTNtMq2=ny5i73wKfg+-ag4c6VviP@mail.gmail.com>
References: <AANLkTikVpDrnqxhBTNtMq2=ny5i73wKfg+-ag4c6VviP@mail.gmail.com>
Message-ID: <4D87B0A9.6000701@crosswire.org>

Would you fill out an issue in Jira? I think I know where in the code 
the problem is, but if you'd include a JUnit test case I'll add that too.

In Him,
     DM Smith

On 03/21/2011 04:06 PM, Martin Denham wrote:
> Hi,
>
> Some Books like Pilgrim's Progress and Edersheim have keys with 
> identical names but different parents.
>
> Here is an example from Pilgrims Progress:
>    Part I/The First Stage
>    Part II/The First Stage
>
> So if I have a key1='The First Stage' (in Part II) and I go through a 
> list of keys looking for a key that equals key1 I will arrive at the 
> wrong key.
>
> I am currently changing my code so that if a TreeKey has a parent I 
> also compare parents but I was wondering if you think the KeyTree 
> equals method in JSword should be extended to check parents.
>
> If the above isn't clear I can create a simple junit so show the 
> problem because I may possibly be taking the wrong approach.
>
> Regards
> Martin
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20110321/4c6c32dd/attachment.html>

From jira at crosswire.org  Mon Mar 21 13:53:11 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Mon, 21 Mar 2011 13:53:11 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-183) Comparison of TreeKeys can
 lead to false positives
Message-ID: <905786549.0.1300740791435.JavaMail.tomcat@www.crosswire.org>

Comparison of TreeKeys can lead to false positives
--------------------------------------------------

                 Key: JS-183
                 URL: http://www.crosswire.org/bugs/browse/JS-183
             Project: JSword
          Issue Type: Bug
          Components: o.c.jsword.passage
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: DM Smith


It could be that TreeKey comparison should also compare parents because some books like Pilgrim's Progress can have keys with identical names but different parents.

Here is a junit
	Book book = getBook("Pilgrim");
	
	// flatten and cache all the keys 
	List<Key> cachedKeyList = new ArrayList<Key>();
	for (Key key : book.getGlobalKeyList()) {
		cachedKeyList.add(key);
	}

	// get Part II/First Stage key
	Key partIIFirstStage = cachedKeyList.get(20);
	assertEquals("wrong key", "THE FIRST STAGE", partIIFirstStage.getName());     // these 2 tests pass fine
	assertEquals("wrong key", "PART II", partIIFirstStage.getParent().getName()); // they just clarify which key we have
	
	// now try to find the above key in our cached list of keys but the wrong key is returned
	int indexOfKey = cachedKeyList.indexOf(partIIFirstStage);
	// this test fails because Part I/First Stage is returned instead of Part II/First Stage
	assertEquals("Wrong index", 20, indexOfKey);


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira at crosswire.org  Mon Mar 28 14:33:00 2011
From: jira at crosswire.org (DM Smith (JIRA))
Date: Mon, 28 Mar 2011 14:33:00 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-184) Change BibleNames to be an
	enum
Message-ID: <493911419.1.1301347980819.JavaMail.tomcat@www.crosswire.org>

Change BibleNames to be an enum
-------------------------------

                 Key: JS-184
                 URL: http://www.crosswire.org/bugs/browse/JS-184
             Project: JSword
          Issue Type: Sub-task
    Affects Versions: 1.6
            Reporter: DM Smith
            Assignee: DM Smith
             Fix For: 1.6.1


BibleNames currently is a set of constants numbering the books of the Bible from 1 to 66, from Genesis to Revelation.
This poses two problems to alternate versification:
* These numbers are often used as indexes into arrays. This presumes that the KJV ordering of the books is what every v11n uses. Not so.
* The range precludes apocryphal/deuterocanonical books.
For details, see: http://crosswire.org/wiki/OSIS_Book_Abbreviations

The av11n implementation in SWORD allows for books to be in any order and for "additional" books to be in either the OT or NT data files. It did not add a third set of data files.

By having an enum of the books we can pass around a BibleBook object.

The impact of this change is significant. Probably the most significant is the Verse class.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira at crosswire.org  Tue Mar 29 14:41:03 2011
From: jira at crosswire.org (Chris Burrell (JIRA))
Date: Tue, 29 Mar 2011 14:41:03 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-185) Concurrency issue with
 JSword - bd1.getSAXEventProvider(); throws "Root Element not set"
Message-ID: <589150380.10.1301434863151.JavaMail.tomcat@www.crosswire.org>

Concurrency issue with JSword -  bd1.getSAXEventProvider(); throws "Root Element not set"
-----------------------------------------------------------------------------------------

                 Key: JS-185
                 URL: http://www.crosswire.org/bugs/browse/JS-185
             Project: JSword
          Issue Type: Bug
    Affects Versions: 1.6
            Reporter: Chris Burrell
            Assignee: DM Smith
             Fix For: 1.7


Caused by: java.lang.IllegalStateException: Root element not set
	at org.jdom.Document.getRootElement(Document.java:218)
	at org.crosswire.jsword.book.filter.osis.OSISFilter.parse(OSISFilter.java:149)
	at org.crosswire.jsword.book.filter.osis.OSISFilter.toOSIS(OSISFilter.java:74)
	at org.crosswire.jsword.book.basic.AbstractPassageBook.getOsisIterator(AbstractPassageBook.java:90)
	at org.crosswire.jsword.book.BookData.getOsisContent(BookData.java:157)
	at org.crosswire.jsword.book.BookData.getOsisFragment(BookData.java:100)
	at org.crosswire.jsword.book.BookData.getSAXEventProvider(BookData.java:113)
	at com.tyndalehouse.step.core.service.impl.JSwordServiceImpl.getOsisText(JSwordServiceImpl.java:131)
	at com.tyndalehouse.step.core.service.impl.BibleInformationServiceImpl.getPassageText(BibleInformationServiceImpl.java:57)
	at com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:101)
	at com.tyndalehouse.step.rest.controllers.BibleController.getBibleText(BibleController.java:60)
	... 28 more


    @Test
    public void testConcurrencyIssueOnBookData() throws NoSuchKeyException, BookException,
            InterruptedException {
        final String[] names = { "KJV", "ESV" };
        final String ref = "Rom.1.1";

        final Runnable r1 = new Runnable() {
            @Override
            public void run() {
                final Book b0 = Books.installed().getBook(names[0]);
                BookData bd1;
                try {
                    bd1 = new BookData(b0, b0.getKey(ref));
                    bd1.getSAXEventProvider();
                } catch (final NoSuchKeyException e) {
                    e.printStackTrace();
                } catch (final BookException e) {
                    e.printStackTrace();
                }

            }
        };

        final Runnable r2 = new Runnable() {
            @Override
            public void run() {
                final Book b0 = Books.installed().getBook(names[1]);
                BookData bd1;
                try {
                    bd1 = new BookData(b0, b0.getKey(ref));
                    bd1.getSAXEventProvider();
                } catch (final NoSuchKeyException e) {
                    e.printStackTrace();
                } catch (final BookException e) {
                    e.printStackTrace();
                }

            }
        };

        int ii = 0;
        while (ii++ < 1000) {
            final Thread t1 = new Thread(r1);
            final Thread t2 = new Thread(r2);
            t1.start();
            t2.start();

            t1.join();
            t2.join();
        }
    }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira at crosswire.org  Thu Mar 31 10:32:03 2011
From: jira at crosswire.org (Martin Denham (JIRA))
Date: Thu, 31 Mar 2011 10:32:03 -0700 (MST)
Subject: [jsword-devel] [JIRA] Created: (JS-186) BibleNames updates for
	Hebrew and French
Message-ID: <1481292193.0.1301592723918.JavaMail.tomcat@www.crosswire.org>

BibleNames updates for Hebrew and French
----------------------------------------

                 Key: JS-186
                 URL: http://www.crosswire.org/bugs/browse/JS-186
             Project: JSword
          Issue Type: Improvement
          Components: i18n - Translation
    Affects Versions: 1.6.1
         Environment: All
            Reporter: Martin Denham
            Assignee: Martin Denham
            Priority: Minor
             Fix For: 1.6.1


I have been sent BibleNames_fr.properties(French) with short names fully populated.
And BibleNames_he.properties (Hebrew) containing 1 fix (2 Cor instead of 1 Cor) and some other minor improvements.
I have these so can check them in now.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira