ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Redirecting output of one (or more) tasks?
Date Mon, 25 Sep 2000 13:43:48 GMT
>>>>> "NS" == Nico Seessle <> writes:

 NS> Two solutions came to my mind:

 NS> 2. It would be possible to create a task that accepts *any* other
 NS> task as a nested element

 NS> but I wanted to know what others are thinking about solution 2.

 NS> I could only think of the following argument against it:

 NS> It opens ant to things we don't want to have (for example
 NS> <conditional if="..."> <task1/> <task2/> </conditional> )

 NS> So what do you think?

I'd word this as "things we don't want to have in the core of Ant". 

I really don't feel like forcing my view of the world on everybody
else, so if anybody wants to write a task that does loops, switch like
constructs whatever, go ahead - in your private copy.

What I don't see is how we could implement something like this without
destroying the contract between Ant's core and tasks: "If you support
nested element X, you need a createX or a addX method that satisfies
conditions XYZ".

One could invent another envelope (Carlos Pita made such a proposal
months back - search for NestingTask - unfortunately it came in a very
busy time and didn't get the attention it might have
deserved). ProjectHelper would know the things nested into an instance
of NestingTask had to be Tasks themselves.

I'm not really happy with something like this, but wouldn't veto it
out either (others might do).

And with regard to logging on a task by task basis, I don't really
think it needs a construct like this at all. We've had proposals for
loglevel attributes (to temporarily switch to verbose logging) or
logfile (to specify a logfile for a task). Don't you think, this could
be solution number 3?


View raw message