modifying source from within ant (to auto-version code)

[Mike Curwen]

I've skimmed the ANT docs, but don't see a task that 'looks' like what I'm describing:

package com.mycompany.utils;
 
import java.util.*;
import com.mycompany.someotherpackage;
 
public class FooStuff implements versioned {
  private int ver_major = 1;
  private int ver_minor = 14;
  private String ver_build = "24/06/2003 10:10:10";
  
  public String getVersion() {
      return "" + ver_major + "." + ver_minor + "_" + ver_build;
  }
 
}

So here, we have a class that implements 'versioned', so we have to supply a method called getVersion().

The question is... is there a way to get an existing ant task to inspect the source for the ver_build String, and to auto-update the date to the current timestamp?

I vaguely am aware of using $Revision$ in CVS to accomplish versioning. But I want to be able to manually figure out the major and minor releases and have only the build number automated (and based on a timestamp, not revision numbering, which CVS uses).

FYI, for my scheme:
major -> signifigant new functionality, or a changed interface (meaning 2.x *breaks* apps that use 1.x, so not just 'enhanced')
minor -> enhancements to the interface (new methods) and bug fixes within existing methods.
build -> identifies the exact time the major.minor version was last compiled.

ANT experts help a newbie please!

[Mike Curwen]

Hmm.....

ver_build = "$Date$";

So if they're compiling and what-not on localhost, it will work, but the getVersion method would return "2.14_$Date$".

But when they "check back in" (a single task that will update CVS, compile, jar and optionally deploy) ... it will timestamp the file and the compiled version from the "check back in" task will get the actual date.

But my question still stands... what about if I'm not using CVS ?

[Frank Carver]

I use ant's built-in filtering for this sort of stuff.
I keep files which need to have tokens substituted at build time in a separate parallel directory structure and do an ant "copy" operation with filtering enabled into the "real" source directory before I start the compilation.
It's easy to set up filter tokens either statically in the build file itself, from a resource such as a properties file, or from an ant variable (like the date from a TSTAMP).
Is this what you are looking for?

[Bear Bibeault]

I do this in the same manner as Frank. I can post some examples if you'd like...
hth,
bear

[Mike Curwen]

'filtering' you say... hmm.....

yah, I think I might need an example.

And it would be "all" files, because I want the timestamp to basically say "someone was here and did a compile". So I'm not sure if I can 'filter' without the 'copy' from a parallel directory.
I'll look into it myself as well.. but I learn by example faster, so feel free to post a small example Bear.

And thanks.

[Frank Carver]

And it would be "all" files, because I want the timestamp to basically say "someone was here and did a compile".
That's even easier, copy and filter the whole lot before compiling.
So I'm not sure if I can 'filter' without the 'copy' from a parallel directory.
Why is this a problem? It's part of the "zen" of Ant. Don't be afraid of copying, it's the way ant makes changes. After all, what is a compile from java source to class files if not a copy-and-transform operation?
As for an example:

  <target name="compile">
    <tstamp/>
    <property name="now" value="${DSTAMP}-${TSTAMP}"/>
    
    <filter filtersfile="src/project.prp"/>
    <filter filtersfile="src/configs/${config}.prp"/>
    <filter token="now" value="${now}/>
   
    <mkdir dir="tmp"/>
    <copy todir="tmp" overwrite="true" filtering="on" flatten="false">
      <fileset dir="src">
        <include name="**/*.java"/>
      </fileset>
    </copy>
    <mkdir dir="classes"/>
    <javac srcdir="tmp" destdir="classes" debug="on">
      <classpath refid="classpath"/>
    </javac>
  </target>

Does that help ?

[Bear Bibeault]

Frank beat me to the example! Mine wouldn't add anything that Frank's doesn't cover, so I won't post it (unless someone specifically requests it as further data).
bear