Patch was Re: [jsword-devel] big checkin

[Joe Walker]

I think you are probably right.

Theoretically you could argue that if everyone took the same approach 
then we'd all need CVS to everything to get anything done.
However practically speaking that isn't the effect of what we are doing, 
  and in reality developers aren't going to be working on a single 
project in the short term anyway.

I'll carry on applying patches, and merging with the changes I've been 
making.

Thanks,

Joe.


DM Smith wrote:
> My two cents and I am not being defensive and if you wish to pitch the 
> changes, that would be fine w/ me.
> 
>  From a mechanical perspective there are two dependencies expressed in 
> the changes I made:
> 1) The .classpath file contains references from one project to another. 
> While there were a few of these references, they are now complete.
> 2) The build.xml now pulls in what it needs from one project to another.
> 
> To work on jsword alone, one would need common.jar and common-src.zip 
> (for debugging), along with the external jars held in the jar directory.
> These would have to be current with the baseline of jsword being worked on.
> 
> To work on bibledesktop alone, one would need:
> common.jar, common-src.zip and its external jars.
> jsword.jar, jsword-src.zip, jsword-osis.jar, jsword-osis-src.zip and its 
> external jars.
> These would have to be current with the baseline of bibledesktop being 
> worked on.
> 
> To support this independent development, I see a few things that would 
> need to happen:
> 1) We would need to publish jars and zips from each project 
> independently each time they changed. We may also need to rebuild and 
> publish jars for other projects on which the modified project is a 
> dependency. I have found that this is not always obvious and is easier 
> to manage by an "always" policy. That is, if jsword changes then assume 
> bibledesktop changes.
> 
> 2) We would need to:
>   a) create another set of ant files which could be used for independent 
> development.
>   b) provide explicit instructions on how to build in that environment: 
> e.g. what files to copy, where to put them, ....
> 
> 3) Development on dependencies would need to be very stable. If changes 
> to bibledesktop require changes to jsword or common, then jsword and 
> common are not stable.
> 
>  From a practical perspective of a starting developer using Eclipse and 
> connecting to CVS, my guess is that such a developer will want to see 
> all of the code to gain an understanding of it. So these changes 
> minimize the size of the download (jars only live in one location) and 
> make it more likely that a user on a dialup can work on it.
> 
> Once we reach development stability, I think it would be reasonable to 
> provide a set of ant build files that would allow independent development.
> 
> Joe Walker wrote:
> 
>>
>> Thanks.
>> I think I'm happy with this, but I did want to just check on a 
>> difference in style to make sure we were doing the right thing.
>>
>> Previously if a developer wanted to work on bibledesktop alone (or any 
>> of the other projects for that matter) they could copy in the jar 
>> files built by other projects and carry on on working.
>>
>> With this patch we are saying that to work on bibledesktop from CVS 
>> you must also have jsword and common from CVS.
>>
>> Are we right in making this change?
>>
>> Joe.
>>
>> DM Smith wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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