Hi, ------------------------------------ CONTEXT ------------------------------------ I have 2 build.xml files and both of them are importing common.xml The first build.xml is calling the second build.xml. And the second build.xml is calling a macro of the common.xml This macro have the following definition: <property name="jar.dir" location="build/jar"/> <!-- generated jar files --> ... <macrodef name="common-jar"> <attribute name="dir" default="${jar.dir}" Description="Directory in which to create the jar file"/> <sequential> <echo> DEBUG INFO :: COMMON-JAR jar.dir=${jar.dir} @dir=@{dir} </echo> <mkdir dir="@{dir}"/> ... </sequential> </macrodef> ------------------------------------ PROBLEM ------------------------------------ When the macro is called without defining the attribute "dir", it uses the default value... look at those traces: [echo] DEBUG INFO :: MMS-JAR [echo] jar.dir=Y:\mmsoe\common\build\jar [echo] @dir=Y:\mms_testtools\tstauto\build\jar The value contains in the @dir attribute is not the same as the property's value ${jar.dir}... in fact, it is the one that was defined when common.xml was imported by the FIRST build.xml.... And I only get this problem when building with ant 1.6.3 (not with ant 1.6.2 or 1.6.1)
can you distill this down to three working buildfiles that reproduce the error and attach them with clear intent as to what to execute in order to trigger the problem? Thanks, Matt
Created attachment 15190 [details] to test the bug Go to the directory _build1 and run the target "cmd.build2" from the build.xml
I get: Buildfile: build.xml cmd.build2: build2.jar: [echo] [echo] DEBUG INFO :: COMMON-JAR [echo] jar.dir=D:\javaWorkArea\mariesoleil\_build2\buil d\jar [echo] @dir=D:\javaWorkArea\mariesoleil\_build2\build\j ar [echo] [mkdir] Created dir: D:\javaWorkArea\mariesoleil\_build2\build\jar BUILD SUCCESSFUL Total time: 0 seconds This looks correct to me... what is wrong with this result?
BTW, I tested with Ant 1.7 and what will be Ant 1.6.5; There have been no changes from 1.6.3 to 1.6.5 that should have any impact on this.
This is a bug. It was caused by an incorrect fix to bug 31215. I have committed a fix and a test for the fix. The fix will be in 1.6.5. Thanks for the timely report!