Does Ant offer a way to bypass dependency?

Question

The build.xml has a test and a build target. The test target obviously depends on the build target.

How can I run the test target on

Answer 1

Use the unless attribute.

<target name="test" unless="dont.run.tests">

If you don't want "test" to run, just

ant -Ddont.run.tests=true

It should be undefined if you want the tests to run. Ant just checks for whether it's defined at all. Also, there's an if attribute that does the converse.

Here's an article on the both.

Answer 2

Just "remove" the dependency temporarily?`If the code is built already all your files should be available, no? - oops, just saw that you cannot alter the file, hmm, why don´t you run the same job locally first?

Answer 3

No, you can't skip it without modifying the build file.

Here is what I do in my projects to solve this issue. For every public target I will create a private target with "do-" in front of it. The private target has no dependency, and the public target has the "do-" target as a dependency.

For example:

<target name="compile" depends="init, do-compile" description="Compiles all of the source code" />

<target name="do-compile">
        <javac destdir="${classes.dir}" debug="true" encoding="ISO-8859-1">
            <src refid="src.path" />
            <include name="*.java" />
            <classpath refid="external.libraries.classpath" />
        </javac>
</target>

Answer 4

A well written build target will not need to rebuild anything if the code hasn't changed. So the fact that the test target depends on it should be largely irrelevant. If you run the build target twice in a row and it tries to rebuild something the second time, you might want to investigate why it is doing that.

The simple way to avoid executing the target is to set the "unless" attribute of the target to the name of some property. If you then set this property on the command line when running Ant, it will bypass that target.

Answer 5

Personally I've found the dependency stuff in Ant to get in the way more than helping. I usually set up two sets of targets - ones which actually do stuff (with no dependencies) and then targets which just have dependencies. That way you can easily run a single target, and you can also easily run the whole suite etc. This fits in with practical (rather than ideological) uses in my view.