Keiron Liddle wrote:

>On Tue, 2002-05-21 at 05:46, Peter B. West wrote:
>>Ladies and gentlemen, boys and girls,
>>What's the state of play now with the changes to the build system?  Has 
>>the elimination of Xalan1 been completed?  Who's doing what there?
>>I am planning to throw a branch off HEAD to tinker with at least the 
>>versioning information for the build.
>What exactly do you want to do with the versioning etc.
>Can you give us a rundown of what it will do and how?
>btw If you want to "tinker" with cvs you can do it all on your own


The full range of what I want to do with versioning I am not sure of; 
the minimum I am sure of.  I canvassed this a short time ago.  That is, 
to eliminate the situation where the identification of a build depends 
on manual intervention in the build.xml file which may or may not match 
a tag in the CVS tree, which may or may not correspond to the full set 
of files in the release.  I am astonished that this situation is 
tolerated, although I should not be astonished to be told that it is the 
general condition of Ant-based builds.

The first thing is to get the version information returned by the 
Version class to match a tag.  That's easy.  Include $Name$ and $Header$ 
in as, say, private static final String fields, and include 
getTag() and getHeader() methods which simply return those values. 
 Modify getVersion() to manipulate the $Name$ tag value, expressed 
according to the convention which I have also canvassed, without 
response, here earlier.  If there is no $Name$ value, a default version 
string, something like "FOP.Development" (a string which could not be 
generated from a legitimate tag) would be returned.

That, obviously, is fairly easy to do.  Trickier problems include:

Reporting the new getVersion() string during the build.  Done fairly 
easily by an Ant task which simply emits the derived string to the 
normal verbiosity stream.  Should probably involve similar labelling 
procedures in and build.xml.

Validating that the whole source tree corresponds to the tag in  This necessarily involves the inclusion of keywords in 
every source file of the build.  Now there's a novel idea.  Another task 
required, and it would be useful if I could get the canonical tag value 
back into the build somehow, as for example with backquotes in a 
shell-based unix build process.  I don't know how to do this in Ant.

I want to look at all of these things, but clearly not all before 0.20.4.

Let me say a few words about the CVS tree.  It's not a sacred site.  It 
has branches in order, among other things, to enable isolated 
development.  IMHO, all individual development should take place on 
personal branches, unless multiple developers are closely co-ordinating 
attacks on particular pieces of code.  Make changes, find out what 
others are up to, merge into your own branch from the trunk as 
necessary, and when you're ready, notify everyone that you want to merge 
back to the trunk.  Do that.  Find, and resolve with the other 
developers any merge conflicts.  Abandon the branch.  Throw another one 
and move on.  This tool allows such things to happen and protects 
everybody's investment, so let's take advantage of it.  If a branch is 
abandoned without ever being integrated into a release, so what?


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to