7 Replies Latest reply on Mar 27, 2006 10:15 AM by alexfu.novell

Ant task antcall vs call

alexfu.novell Mar 22, 2006 5:26 PM

In JBoss/Messaging build.xml we have the following target:

 <!-- Compile manifests -->
 <target name="compile-etc" depends="init">
 <mkdir dir="${build.etc}"/>
 <copy todir="${build.etc}" filtering="yes">
 <fileset dir="${source.etc}">
 <include name="**"/>
 </fileset>
 </copy>
 </target>

Notice that the filtering option is set to "yes" for the copy task. It is expected that during the copying, the default filter will replace all tokens in the files with values if the token matchs any property name. For example, file default.mf contains the following line:

Created-By: @java.vm.version@

Once it's copied from source.etc to build.etc, @java.vm.version@ should be replaced by 1.5.0_06 or something.

However, it only works in the following situations:
(1) compile-etc is called by

<call target="compile-etc"/>

(2) compile-etc is called by

<antcall target="compile-etc" inheritAll=false/>

It doesn't work (@java.vm.version@ won't be replaced at all) in the following case:

<antcall target="compile-etc"/>

Two questions here:
(1) I couldn't find any ant document explaining . Is it a deprecated task? We still use it in several projects (naming, server, etc.) though.
(2) I'm sure the property is transferred to the called target then why the default filter doesn't do the job correctly? Does anyone have similar experience?

Does anyone happen to know the answers? Thanks.

1. Re: Ant task antcall vs call

ruel.loehr Mar 22, 2006 5:57 PM (in response to alexfu.novell)
How are you using antcall?

I wrote a quick target:

<target name="filtertest"> <antcall target="compile-etc"/> </target>

and then execute

./build.sh filtertest

The manifest is compiled correctly. Can you post your target which contains the antcall?
Actions
2. Re: Ant task antcall vs call

alexfu.novell Mar 23, 2006 8:58 AM (in response to alexfu.novell)
I simplified the situation in my first post.
"compile-etc" is not "antcall"ed directly, but through several depends.

Here is a very simple test that can reproduce the problem:

If you go to jboss-head/naming project and change the following line of build.xml:
Line 230: <call target="compile"/>

to
<antcall target="compile"/>

then after a clean build, you will find output/etc/default.mf appears as the following content, without any substitution:
Manifest-Version: 1.0 Created-By: @java.vm.version@ (@java.vm.vendor@) Specification-Title: @specification.title@ Specification-Version: @specification.version@ Specification-Vendor: @specification.vendor@ Implementation-Title: @implementation.title@ Implementation-URL: @implementation.url@ Implementation-Version: @implementation.version@ Implementation-Vendor: @implementation.vendor@ Implementation-Vendor-Id: @implementation.vendor.id@
Actions
3. Re: Ant task antcall vs call

ruel.loehr Mar 23, 2006 4:04 PM (in response to alexfu.novell)
Alex,

<call target="compile-etc"/>

To answer your questions:
1) "Call" is a buildmagic task. You won't find any docs on the ant website for it.
2) Ant maintains 2 hashtables for storing properties, a general hashtable and a user hashtable. Antcall creates a new ant project from the build.xml in naming and passes all the properties from the general hashtable to the new project. By specifying inheritAll=false you the properties in the user hashtable to be copied.

Buildmagic exends the core ant functionality and stores the properties you are looking for as "user properties".

<taskdef name="property" classname="org.jboss.tools.buildmagic.task.Property" classpathref="buildmagic.task.classpath"/> ---------------------------------------------------------- if (system) { log.verbose("setting system proeprty: " + name + "=" + value); System.setProperty(name, value); project.setUserProperty(name, value); }

So by adding the inheritAll=false attribute to ant call,you are getting props you need.
Actions
4. Re: Ant task antcall vs call

alexfu.novell Mar 23, 2006 5:12 PM (in response to alexfu.novell)
Thank you for the explanation. However I think the problem is beyond the property propagation.

Reason:

Still using jboss-head/naming as example, if I add the follow echo to <compile-etc> task:
<target name="compile-etc" depends="init"> <echo message="XXXXXX ${java.vm.version}"/> <mkdir dir="${build.etc}"/> <copy todir="${build.etc}" filtering="yes"> <fileset dir="${source.etc}"> <include name="**"/> </fileset> </copy> </target>

Then if I do a clean "build jars" (which will do
<call target="compile"/>
), it displays the following:
compile-etc: [echo] XXXXXX 1.5.0_05-b05 [mkdir] Created dir: E:\jgroup\jboss-head\naming\output\etc [copy] Copying 4 files to E:\jgroup\jboss-head\naming\output\etc

Then I change the following line
<call target="compile"/>
to
<antcall target="compile"/>
and do a clean "build jars" again,
it still displays the same result for the echo:
[echo] XXXXXX 1.5.0_05-b05

Then if I add inherit="false" to the above antcall and do the same clean build one more time, I get exactly the same echo output.

Thus, at least for java.vm.version, the value is propagated correctly with either call, antcall or antcall inherit="false".

The real problem is that the default filtering (which should replace @java.vm.version@ with the value) doesn't work with antcall but it works with call or antcall inherit="false".

Thanks.
Actions
5. Re: Ant task antcall vs call

ruel.loehr Mar 23, 2006 5:51 PM (in response to alexfu.novell)
The real problem is that the default filtering (which should replace @java.vm.version@ with the value) doesn't work with antcall but it works with call or antcall inherit="false".

Yes! Your are right, but the root of the problem *is* property propagation. I thought the problem was with the userProperties, but I should have looked a step further.

Here is why.

In the file /tools/etc/buildmagic.ent we have a target called _buildmagic:init. This target is only executed if the property init.disable is not set. Inside this target we setup the filters.

 <propertyfilter all="${buildmagic.propertyfilter.all}"/> //this takes the project properties and adds them to the project as filters

You can see it at: http://fisheye.jboss.com/viewrep/~raw,r=1.2/JBoss/buildmagic/tasks/src/main/org/jboss/tools/buildmagic/task/PropertyFilter.java

When you use antcall, with the default settings it includes the property init.disable=true. So, you get a new ant instance, it tries to execute the build, tries to execute _buildmagic:init but can't since the property init.disable=true. Thus, your properties never get set.

[antcall] calling target compile in build file C:\projects\jbosshead\jboss-head\naming\build.xml parsing buildfile C:\projects\jbosshead\jboss-head\naming\build.xml with URI = file:///C:/projects/jbosshead/jboss-head/naming/build.xml Project base dir set to: C:\projects\jbosshead\jboss-head\naming _buildmagic:init: Skipped because property 'init.disable' set.
Actions
6. Re: Ant task antcall vs call

alexfu.novell Mar 23, 2006 8:27 PM (in response to alexfu.novell)

This is really interesting. I think I understand the reason now.

So, I think the best approach is to use "call" instead of "antcall" in build.xml. Am I right? Since the current messaging build.xml is using antcall, do you think switching to "call" will have any bad side effects?

Thanks.
Actions
7. Re: Ant task antcall vs call

alexfu.novell Mar 27, 2006 10:15 AM (in response to alexfu.novell)

Ruel,

Where can I find the definition of "call"? Is it a good replacement of "antcall" under JBoss build system?

Thanks.
Actions

Go to original post