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 >machine. > >
Keiron, 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 Version.java 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 Version.java and build.xml. Validating that the whole source tree corresponds to the tag in Version.java. 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? Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
