-
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? -
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@
-
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. -
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. -
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.<!-- Install 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.
-
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. -
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.