ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Monsarrat <>
Subject Migrating form ANT 1.6 to 1.7: xmlproperty
Date Tue, 19 Feb 2008 13:48:05 GMT
I am attempting to migrate a large ANT build system from 1.6 to 1.7 and 
am running into a problem with xmlproperty.
We use xmlproperty massively in our build system and very often "stack" 
several xmlproperty calls in order to build a complex property 'tree', 
where several inter-dependent build files will declare and/or overload 
parts of the tree using xmlproperty.
Our approach however is completely incompatible with ANT 1.7 due to a 
modification to xmlproperty (bug 26286 c.f. that forces 
"empty" elements in an XML property tree to be declared.

Consider the following exemple:
===> build_A.xml :
<project  name="Bui_A" default="All">
    <xmlproperty file="about_A.xml"/>
    <import file="build_B.xml"/>
    <target name="All">
        <ant target="Bui_B.main"/>

===> about_A.xml:
    <version developmentStage="beta"/>

===> build_B.xml :
<project  name="Bui_B">
    <xmlproperty file="about_B.xml"/>
    <target name="Bui_B.main">
       <echo message="The version number is: '${app.version}'"/>
       <echo message="The development stage is: 
       <!-- etc.... -->

===> about_B.xml:
    <version developmentStage="final">2.4.0</version>

The aim is : When running build_A.xml use most of about_B.xml but 
overload certain parts of it with about_A.xml

In ANT 1.6 about_A.xml would only set property 
app.version(developmentStage) effectively overloading the 
developmentStage defined in about_B.xml, but with ANT 1.7, about_A.xml 
also sets the property app.version to "empty" thus making it impossible 
for about_B.xml to define it as 2.4.0.

In ANT 1.6 the output  is:
[echo] The version number is: '2.4.0'
[echo] The development stage is: 'beta'

in ANT 1.7 the output is:
[echo] The version number is: ''
[echo] The development stage is: 'beta'
This makes it impossible to use xmlproperty to overload a single path in 
a complex property tree, and therefore destroys one of the main features 
of the task as far as I can see.
Has anybody come across the same problem? any workaround?

View raw message