Patch was Re: [jsword-devel] big checkin

DM Smith dmsmith555 at yahoo.com
Sat May 1 17:19:58 MST 2004


Attached is a zipfile with three patches. As always, apply them in the 
order: common, jsword, bibledesktop.

Here is a summary of the changes:
common:
  etc/eclipse add 2 launch files and delete 1
  remove java/config/org/crosswire/common/config/test.properties
	(it was not being used)
  modify .classpath
  modify .cvsignore (added common.keystore)
  modify build.xml
  add core.xml

jsword:
  etc/eclipse added 2 launch files, modified 1 and deleted 1
  removed jar/jdom*
  removed jar/lang*
  modified .classpath
  modified build.xml

bibledesktop:
  etc/eclipse add 5 launch files and delete 1
  remove jar/jdom*
  remove jar/lang*
  modify .classpath
  modify .cvsignore (removed bibledesktop.keystore)
  modify build.xml

Below explains the changes:

I wanted to learn ant and I hope the changes that I have made are 
acceptable. In looking at Joe's changes, I saw that common, jsword and 
bibledesktop took the approach that they merely build their jar files. 
All the extra stuff was left in jsword-web.

I continued this approach, modularizing the build.
I made common the home for core.xml which is imported by the build.xml 
files in common, jsword and bibledesktop. Core.xml takes the perspective 
that:
1) A project may have an immediate dependency upon another project which 
must be satisfied first. That is bibledesktop depends upon jsword which 
depends upon common. Thus, bibledesktop invokes a corresponding build in 
jsword, which in turn does the same in common. And common which does not 
have any dependencies does not need to call another build.xml.

2) The basic flow is clean, prepare, compile, jar. For each of these 
tasks (except clean) there there is a hook to allow for extra work to be 
done.

2a) Clean wipes out all of target/ant. (Same as before)

2b) Prepare copies all the needed jars out of "project"/jar/* into 
target/ant/jar and it copies all of the jars from the project upon which 
it depends. As the jars are copied they are signed. Junit is treated as 
an anomaly since it is not needed except for test code. It is used 
directly from "project"/jar.

With regard to signing the jars as they are moved/built to target.jar, 
this simplified the ant code for signing significantly.

2c) compile, like before, creates class files in target/ant/classes. But 
with two differences. First, there is not a separate directory for each 
source folder (e.g. java/main, java/core, java/config, java/swing). They 
are all dumped together. Since all the resources are managed in the 
resource directory and not along side their java files, I removed the 
code to look for adjacent resources.

Test code is compiled to target/ant/test/classes.

2d) Jar creates a jar file for the project. The resources are stored in 
the same jar as the project, just as Joe last did. And the test code is 
left as class files and not put into a jar.

To support these tasks I created Eclipse ant launch files for all, clean 
and build. (And I removed the ones I broke).

There are some good consequences of copying jar files from a dependency. 
It means that we only need to manage a jar file in the first project 
along the dependency chain that uses it. The copying is version/release 
insensitive. So if we upgrade winlaf-0.4 to winlaf-0.5, the build files 
do not need to change. I have deleted the redundant jars, except 
junit.jar, since I am not sure how those targets will be written.

I also made changes to each project's build path. I explicitly marked 
what is exported from one project to another and removed those jars that 
could be imported in this fashion. I also ordered the jar files so that 
they were first in the list of the project's children and were 
alphabetized. I sub-ordered the list by having the jars that were used 
internally (i.e. in building a jaxb version of osis) after the exported 
jars, alphabetized.

Since this is a bit of a change, I have fully commented core.xml (except 
for cvsup, since I don't know exactly what it does and since I could not 
test it.)

I have not touched jsword-web. So I may have broken it's build.

Joe Walker wrote:
> 
> The tricky thing is what to do with the jar files.
> The approach taken at the moment is that each project:
> - contains all the jars needed to build in the jar directory
>     - unless those jars are created by another jsword project
> - has a output target that creates a folder containing useful exports
>     - including jars depended on by created jars
> 
> Hence log4j.jar is only in common since all the other projects use the 
> log wrapper in common.
> However all projects export log4j.jar (having copied it from common) 
> since they need it to run.
> 
> I am tempted to make ant (and even eclipse) work off created jar files 
> copied into the project (so there is a copy of common.jar in jsword, and 
> a copy of jsword.jar and common.jar in bibledesktop)
> However I haven't because I think that would dislocate the projects too 
> much, forcing you to copy jars around too much, and breaking refactoring.
> 
> So I've separated the projects as much as a I could without making too 
> much extra work. At least this way the dependencies are fairly explicit.
> 
> I have not added and targets to build dependent projects yet.
> 
> Joe.
> 
> 
> DM Smith wrote:
> 
>> Thanks Joe.
>> I am back up and running. Your solution looks a lot like what I got to 
>> work. It is stripped of everything but what is needed to get the 
>> solution to work!
>>
>>
>> Joe Walker wrote:
>>
>>>
>>> Hi,
>>>
>>> Big check-in going on as we speak. The ant builds for common, jsword 
>>> and bibledesktop now work OK for me. Next the tough one - jsword-web.
>>>
>>> Joe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchbuild.zip
Type: application/x-zip-compressed
Size: 15076 bytes
Desc: not available
Url : http://www.crosswire.org/pipermail/jsword-devel/attachments/20040501/fafd0841/patchbuild-0001.bin


More information about the jsword-devel mailing list