ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject RE: [PATCH] Ant task inheritAll bug
Date Wed, 05 Sep 2001 07:43:25 GMT
Thanks Jason,

I applied the patch and did a little bit of renaming as well as added some
javadocs to comment source code. I'm not familiar with all the magic here
and don't have much time, so if Craeg could do something here I would be
very happy.

I think this <ant> and <antcall> are extremely important and we really need
testcases and docs since they are used extensively in many different maneers
in nearly all complex build file I saw.


 Stephane Bailliez 
 Software Engineer, Paris - France 
 iMediation - 
 Disclaimer: All the opinions expressed above are mine and not those from my

> -----Original Message-----
> From: Jason Brittain []
> Sent: Wednesday, September 05, 2001 12:17 AM
> To:
> Subject: [PATCH] Ant task inheritAll bug
> NOTE: the below bug affects only Ant 1.4 (including the
> betas) and above.
> While reading through the Ant task source I noticed a
> bug.  The wrong variable name had been used for a
> Project object.. two were being used, one called "p1"
> and another called "project".  The line of code that
> was wrong used the wrong variable name -- it used
> "project" instead of "p1".
> The result was that whenever using the "ant" task to
> call a target in another build file with the
> inheritAll attribute set to false, all user and
> system properties are supposed to be copied and
> visible, but actually only the user properties
> are copied, leaving the system properties undefined.
> Attached is a zip containing the patch to fix it,
> plus a test in the form of two build files that
> show output so you can be sure that the bug exists
> and that the patch fixes the problem.
> I've found Ant to be a great tool, and the source
> to be generally nicely readable and understandable.
> Kudos to all contributors for that.  But, I believe
> that this bug happened because of poor naming of
> variables combined with the lack of testing patches
> (since this is a patch to a patch that was recently
> sent in via the mailing list and committed).  If
> the variables were more clearly named, though, it
> would have been less likely for this bug to ever
> have crept in, I think.
> Cheers.
> -- 
> Jason Brittain
> <jasonb at collab d0t net>
> CollabNet

View raw message