1) It's like polluting a tranditional program's variable space
with stuff the application did not explicitly cause -- it makes
debugging more difficult (and confusing if the results of the
Ant execution is published in a readonly format like a website). 2) The previous statement might seem trivial if you only use Ant
to run build scripts. However, I personally dig Ant because I
can use it to do other kinds of things. In particular, Ant is
the foundation script and launch harness for our test management
system. Being able to remove the "Ant fixture bits" from the
test configuration and other system under test bits (and this
includes Ant components) is really important to us. The more
kruft Ant spews into the "Ant fixture bits" the more difficult
it becomes for a QA person to pick out what's important when
something fails. Unless we limit what Ant components the QA/Dev team can use
(we *really* don't want to do this), scrubbing what gets captured
as the "Ant fixture bits" becomes difficult.Is there no way to remove the scoped properties once the target and/or task container is finished?
OK, enuf whining. ---------------- The Wabbit
At 12:40 PM 10/8/2004, you wrote:
Ok, here are my responses:
> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > [SNIP] > 2) All these uniquely named properties go on living after > the macro has executed. That pollutes the namespace. >
Yes it does. But I still have to see a good argument on why shall that bother anyone. Unless you are talking about millions of executions within one project context. You can always mitigate this in some very complex build by using <antcall/> as a way fence out chuncks of temporary properties. But I would like to see a good example in whch this pollution is a real problem.
[SNIP] Jose Alberto
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
