ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Weintraub" <>
Subject Re: using ANT to check for any code changes in CVS
Date Wed, 10 Oct 2007 00:44:36 GMT
CruiseControl and Hudson are good build systems, and that's what it
sounds like you really want. CruiseControl examines your source area
every so often (depending upon the wait period you set). Then, if it
detects a change, it will run your buildfile. That means your
buildfile simply won't be executed unless there has been a source
change. If your buildfile isn't executed, nothing gets built and
nothing gets tested.

However, sometimes, there may be changes in the source that doesn't
really affect your unit tests. For example, maybe helpfiles are
changed. Or maybe source files that affect only one group of tests
were affected, and you only want to run that set of tests instead of
all of your tests. That's where the <uptodate> task and AntContrib's
<outofdate> tasks come into play.

The <uptodate> task is part of the Ant core tasks, so there's nothing
to install. It can compare a large set of sourcefiles against a single
target (usually a jarfile). If the target is older than any source
files, a property is set. You can then run another target based upon
whether or not this property was set.

<target name="test-for-changes">
    <uptodate targetfile="${jar.file}"
            <fileset dir="${src.dir}/">

<target name="unittest"

I personally prefer the AntContrib's <outofdate> task, but that
requires the installation of the AntContrib library. Nothing too
difficult, but it means that each person who wants to run your
buildfile must have the AntContrib library installed. I simply made it
part of the standard installation. The <outofdate> task has several
advantages over the <uptodate> task:

* You can compare multiple targets against multiple sources. If any
target is older than any source file, the <outofdate> task is executed
(unless you used a mapper). For example, you could compare all *.java
files against all *.class files. If any *.java file is newer than any
*.classfile, the tasks inside the <outofdate> task are executed.
* You can put the tasks you want to execute directly inside the
<outofdate> task instead of just setting a property. This makes it
alot easier to maintain your buildfile.
* You can run your tasks in parallel which may mean your tests will
finish faster.
* You can use a mapper to map your source files to your target files.
I've never done this, but this means that you don't execute the
<outofdate> tasks just because is newer than bar.class even
though is older than bar.class.
* Source and Targets may be specified via properties. This is great if
you do an <antcall> or <ant> to your unittests because you can pass
the source and targets as parameters.

<target name="unittests">
           <fileset dir="${}"/>
            <fileset dir="${lib.dir}"/>
        <!-- Now run all your tests in parallel -->

See <>
for the <outofdate> task.
See <> for the
<uptodate> task.

On 10/9/07, Saladin Sharif <> wrote:
> Thanks for the suggestion.   I think this would work out well if my ANT script was only
performing a build.  But reallity is, my ANT script is checking out code from CVS, performing
a build, deploying the application, then performing regression testing, running a large number
of JUnit test cases, then generating a report of the test results.  So even though the build
would be very fast if there were no CVS changes, running the test cases would still take the
same amount of time as it would if there were CVS changes.  That's why I would like my ANT
script to be able to check for CVS changes in order to decide whether to run the regression
tests or not.
> -Saladin
> **********************************************************
> * Saladin Sharif
> * e-mail:
> * Visit homepage @
> **********************************************************
> ----- Original Message ----
> From: David Weintraub <>
> To: Ant Users List <>; Saladin Sharif <>
> Sent: Tuesday, October 9, 2007 7:00:46 AM
> Subject: Re: using ANT to check for any code changes in CVS
> Ant can do an excellent job of build avoidance, so this shouldn't
> really be an issue if you have programmed your build.xml correctly. It
> might still run through all the targets, but no tasks will be
> executed.
> Imagine you have a build.xml like this (the main thing to note that
> each task depends upon the one above):
> [...]
> <target name="cvsupdate">
>     <cvs command="update">
>         [....]
>     </cvs>
> </target>
> <target name="compile"
>     depends="cvsupdate">
>     <javac>
>       [...]
>     </javac>
> </target>
> <target name="jar"
>     depends="compile">
>     <jar>
>       [...]
>     </jar>
> </target>
> <target name="package"
>     depends="jar">
>     <tar>
>         [...]
>     </tar>
> </target>
> Let's say I run "ant package". The "cvsupdate" target runs and checks
> out new files that have been modified. Next, the "compile" target runs
> and builds new *.class files. Then, the "jar" target runs and builds a
> new "jar". Finally, the "package" target runs and builds a new tar
> file.
> Now, I rerun the "ant package" command. The "cvsupdate" target runs,
> but since there has been no files modified in the CVS archive, no new
> *.java files are checked out. Now, the "compile" target is called, but
> since all the *.class files are newer than all the *.java files, no
> *.java files are compiled.
> Now, the "jar" target executes. Since no new *.class files that make
> up my jar have been modified, the "jar" task isn't executed. Now, the
> "package" target runs, but the same thing. No files have been
> modified, so the "tar" command isn't executed.
> I have a build.xml that normally takes about 8 to 10 minutes if I have
> a clean area for building. If I run that build.xml again, it takes
> less than a minute to run through all the targets since it doesn't
> need to execute any tasks.
> Almost all Ant tasks do build avoidance if you take care in writing
> your build.xml file (For example, "copy" and "mkdir" tasks do build
> avoidance, but "move" and "delete" tasks do not). If you do find an
> Ant task that has trouble with build avoidance, you can try using the
> <uptodate> task as a way of checking if a particular target needs to
> be executed:
> <target name="foo">
>   <uptodate property="foo.task.uptodate.flag">
>       [...]
>   </uptodate>
> </target>
> <target name="bar"
>     depends="foo"
>     if="foo.task.uptodate.flag">
>     [...]
> </target>
> Or, if you don't mind using the AntContrib tasks, the <outofdate> task
> allows you to specify inside the task the sub-tasks to execute. That
> saves you from creating a property, then calling another target based
> upon that target.
> So, if you are careful in writing your build.xml, Ant may reexecute
> all of your targets, but it won't execute a single task it does not
> have to. There is no need to verify the output of the <cvs> task to
> see if any new files were checked out.
> On 10/8/07, Saladin Sharif <> wrote:
> > I am trying to automate my ANT build script, and incorporate a check in my build.xml
that checks if there were any code changes made to CVS since the last time the build ran.
 If there are any code changes then ANT gets the latest CVS code changes and then runs the
build.   Otherwise, it doesn't run the build if there were no new code changes in CVS.
> >
> > I was just wondering if anyone knew of how to write the ANT script portion that
would check for whether any new code changes were made in CVS, and then maybe save that outcome
to a property that I can use later on in my ANT script.
> >
> > Thanks in advance,
> >
> > -Saladin
> >
> >
> >
> > **********************************************************
> > * Saladin Sharif
> > * e-mail:
> > * Visit homepage @
> > **********************************************************
> >
> >
> >
> > ____________________________________________________________________________________
> > Pinpoint customers who are looking for what you sell.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> --
> --
> David Weintraub
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ____________________________________________________________________________________
> Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo!
Answers - Check it out.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

David Weintraub

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message