Patch was Re: [jsword-devel] nightly build

[DM Smith]

I agree that CVS is the best solution for someone that wants to stay 
current. We need to continue to do what we can to minimize redundancy 
and unnecessary jars.

I am not sure of the usefulness of the nightly builds. It does appear 
that people with laptops and with modems are reluctant to connect to CVS.

Would it be good to only have the latest successful nightly build? Say 
via, jnlp, zip and tar.gz? Is there a value in having 5 night's worth of 
builds?

Joe Walker wrote:
> 
> On the nightly build front, which of the downloads is actually useful?
> 
> I would guess that nightly source download is not useful, and neither is 
> nightly doc d/l.
> If you want up-to-date then CVS is a better solution for source, and the 
> web a better solution for nightly docs.
> Nightly binaries sounds more useful because not everyone will want, or 
> be able to use jnlp.
> 
> The release situation is different because I can understand people 
> wanting more stable sources to be free of constraints like CVS or the 
> need to be on line (javadoc on the web)
> 
> So I propose a slightly updated version that merges gets rid of all doc 
> and sources nightlies. Given that do we still need to split tools and 
> binaries?
> 
> I'll take OSIS in another mail!
> 
> Joe.
> 
> 
> DM Smith wrote:
> 
>> I am attaching a patch to jsword-web/build.xml that does the 
>> following. Take a look at it and modify it as you see fit.
>>
>> Since I am using a different mail server and program, I am merely 
>> attaching the file. Let me know if it is corrupted.
>>
>> DM Smith wrote:
>>
>>> I was looking at the nightly build and I have a few suggestions:
>>> 1) Since the 3rd party jars don't change frequently, zip them to a 
>>> tools-${version}-bin.zip. This can be built daily until we figure out 
>>> how to do it only when we upgrade a version of a tool. By doing this 
>>> a user can download the tools.zip occasionally.
>>>
>>> Or let people get them from the official location.
>>>
>>> 2) Also publish an osis-${version}-bin.zip and 
>>> osis-${version}-src.zip. Again, this does not change much but they 
>>> are huge. Joe, you have noted that it may be best to migrate from 
>>> jaxb, so this may become a moot point.
>>>
>>> 3) In jsword-${version}-bin.zip only include the following jars 
>>> common.jar, jsword.jar, bibledesktop.jar and maybe jsword-web.jar.
>>>
>>> 4) In the jsword-${version}-src.zip only include the source for 
>>> common, jsword, bibledesktop and maybe jsword-web. This includes the 
>>> contents of their resource directory. I could go either way on 
>>> whether it should contain test source. The idea behind this is that 
>>> if a person wants more than this they can get it via CVS.
>>>
>>> And of course build the corresponding tar.gz versions.
>>>
>>> Currently the last set of zips had the following sizes:
>>> jsword-${version}-bin.zip 13.17M (Note that almost every jar appears 2x)
>>> jsword-${version}-src.zip 14.34M (Note that this contains the jars too)
>>>
>>> With the changes above:
>>> jsword-${version}-bin.zip 0.92M (does not include jsword-web.jar)
>>> jsword-${version}-src.zip 1.03M (does not include test code)
>>> osis-${version}-bin.zip   1.13M
>>> osis-${version}-src.zip   0.82M
>>> tools-${version}-bin.zip  2.15M
>>>
>>> These numbers are based on a quick hack (may be missing a few files, 
>>> such as *.sh and *.jnlp), but should give the right idea as to the size.
>>>
>>> Note that if we fix the redundancy but don't break it out then 
>>> jsword-${version}-bin.jar should have been 4.20M.