Antoine
Thanks for the reply.
Also, please let us know which version of ant you are using.
The bug report http://issues.apache.org/bugzilla/show_bug.cgi?id=21724 describes your problem.
It was detected in ant 1.5.3 and solved in ant 1.6.0
Ant 1.6.2
I think the version was noted in my original email, but must have got chopped off in Dominique's reply.
Have you tried to distill down your builds to something simple enough that can be sent whole for troubleshooting?
In fact I didn't even get as far as this before I spotted it ...
In my top level build.xml, my "vt.class.path" reference has global scope, meaning I don't have to include an "inheritrefs=true" on any <antcall> tasks in my top level script.
In fact, the "vt.class.path" reference is also being passed down to my lower level build scripts in the <subant .... "inheritrefs=true" > call - but with a subtle change, it doesn't appear in my sub-build file with global scope. So top-level targets in this build script can use it fine, but anywhere in my sub-build file that I have an <antcall> I have to include an "inheritrefs=true" to propagate it to any called target in the sub-build script.
So, I guess not strictly a bug, but possibly an inconsistency (or at least a slight "gotcha") that's worth documenting that inheritrefs _does_ pass references down to called script, but it alters their scope.
-- Rob
This is often not a futile exercise, as many times users can't reproduce the failure with a simpler version of their build, and eventually figure out the problem is elsewhere...
This distilled build can simple define an id'd path in the top level build, and echo the refid'd path in the subbuild. I suggest you try this. --DD
PS: IMHO, I see signs that your build may suffer from using too many variables. Removing 'static' variables (the ones that in fact you never need to change) leads to more stable builds in my experience. Use variables only when necessary.
PPS: <import> can often be used to refactor complex multi-file builds. You should consider it if you plan to work on this build again soon.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Ascert - Taking systems to the Edge [EMAIL PROTECTED] +44 (0)20 7488 3470 www.ascert.com
