Wednesday, June 5, 2013

Difference between antcall and depends

Sometime we work without thinking much about the build script and other times we need to change the build scripts. At this time we start thinking about various functions in the language.

So today when I was modifying such build script, then I got stuck between the use of "depends" and "antcall". I did little bit of Googling and I got 2 nice articles.

It is not possible for me to elaborate all the uses of ‘depends’ and ‘antcall’ but I will try to provide little information on these targets.

Depends is an attribute of “target” target.

<target name=”runtarget” depends=”target1, target2, target3”  if="condition">

About specified line says before running “runtarget”, ant must execute target mentioned in the “depends” attributes. If condition is verified once all the targets mentioned in the “depends” attribute have already run.

So execution order will be as follows:
1.                   target1
2.                   target2
3.                   target3
                if(condition == true)
4.                   runtarget
                endif

Let’s take another example.
<target name="A"/>
<target name="B" depends="A"/>
<target name="C" depends="B"/>
<target name="D" depends="C,B,A"/>

In this case if target D is executed then it will run in the following order.
A -> B -> C -> D
In this case target will not be executed twice.

‘antcall’ is a target/task. It invokes another target which exists in the build xmls.

<antcall target=”target1”/>

In this case processing will switch to another target specified in the antcall. Let’s look at the an example to illustrate the functionality.
<target name=”target1” />
<target name=”target2” >
<antcall target=”target1”/>
</target>
<target name=”target3” >
<antcall target=”target1”/>
<antcall target=”target2”/>
</target>

Now on invoking target3, following will be sequence of run.
Target3 -> target1 -> target2-> target1

As you can see, target 1 is run twice as it will called by target 3 independently and target 2 also invoked target 1 internally. Whereas when such duplicity exists in target called by depends attribute, then ant resolves such duplicate target.

Uses of antcall and depends in one example
Requirement: I have to build a project and create a jar file. Building of this jar depends on already build 100+ jar files, which are at some remote location at the starting of the project. If these jar files do not exist locally, ftp these jar files from remote location.

Approach 1: We will copy the jar files irrespective of their existence.
Approach 2: We will check whether jar files exists, if not then we will copy them from server.

Solution:
Approach 1 is not only time consuming but also it involves the risk of copying the file from remote location, which may not exists at time.
Approach 2 is efficient and nice. So let’s write the code for this.

<target name=”CopyJarsFromServer”>
<!—code for copying the jar using ftp -->
</target>

<target name=”validatejars”>
<if condition>
<antcall target=”CopyJarsFromServer”/>
<!—these is not other way to do it without using ant call -->
<end if>
</target>

<!—We are using depends attribute as we want to make sure that jar exists before any actual processing starts -->
<target name=”build” depends=”validatejars”>
<!—relevant code to build the jar -->
</target>

Hurrey, Now I understand the difference between antcall and depends, and I hope you too. J

Misuse of antcall task may hamper efficiency of your build script as antcall task does allow you to control what properties and references are defined (which is why a new Ant environment is created--and why it's so slow) so it can be used to create variants of the same thing; e.g., maybe two jars, one with and one without debug symbols.

So use antcall task only if it is not possible to find a workaround using depends target.

If you didn’t like my explanation and wants to check actual links that I have used to understand the difference, then please visit the followings

3 comments:

  1. ant!!! I tried learning that sometime back. It's too cryptic. I guess, I have to start again now.

    ReplyDelete
    Replies
    1. Na, it is simple and understandable. It is far too simpler than Android coding. :)

      Delete