ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: Token filters
Date Fri, 20 Oct 2000 07:09:15 GMT
quoting to a larger extent this time ;-)

>>>>> "AG" == Alan Gerhard <AGerhard@E-SyncNet.Com> writes:

 AG> What I am aim to do is to stamp each java source with an
 AG> incremental version number each time that particular class gets
 AG> recompiled.  The incremental would be based on the existing value
 AG> in the actual source file.


 AG> Is there something like that already ??

 SB> 	Not exactly, no. Probably not even close to it.

 AG> How do you perform class versioning ??

CVS does for me. I don't want a new version everytime I compile, this
wouldn't fit my personal development style too well (usually, when not
working on Ant, it's "write unit tests first" which can lead to a lot
of compile/test/edit/compile steps before there is something I'm
satisfied with).

So instead of versioning with every compile, I increment the numbers
with every commit. All .java files at work have

// $Header$

at the top and in the javadocs for the class

@version $Revision$

and if I'd need this information at runtime, the classes had

public static String versionID = "$Revision$";

 AG> Well, I'm surprised something like this hasn't come up before.

Something similar has come up. 

Search in the email archives for PropertyFile for example. The idea
here is to hold the version inside a property file and give global
<filter>s a value based on that version - but this would be versioning
of the complete project, not a single file.

You can have the same effetc with the built in <property>, <script>
and <echo> tasks.

Stefan

Mime
View raw message