ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Use cases pleas (was Re: Why Properties became immutable)
Date Tue, 25 Jul 2000 14:31:54 GMT
>>>>> "RV" == Roger Vaughn <> writes:

 RV> And that's what I'm saying I personally don't want to see Ant
 RV> become - so declarative that you don't know what you're getting.

Seems like we all have a common goal. Keep Ant simple and avoid make
like hell. 

 RV> I and others are running into *real world examples* where we need
 RV> this sort of power - and by its lack we are forced to hand-code
 RV> every explicit target and task repeatedly.

Could you please share what kind of constructs these are. I seem to be
too far away from *real world examples* to see all of them. If we all
know what kind of problems to tackle we might come up with the
simplest possible solution together.

If it only was to avoid repeating targets that only differ in the
value of some properties, sub builds seem a lot clearer to me than
anything else I've seen proposed, including template targets and XSLT
like constructs.

Sub builds using the same build file generate an overhead that we can
remove if we switch too runtime evaluation, but I'm actually talking
about syntax here.

<target name="templated">
  <task using ${foo} >

  <calltarget target="templated">
    <param name="foo" value="..." />

is procedural in a sense. Replace "calltarget" with "ant" and "param"
with "property" and we are already there. I'm willing to accept that

I'm still not convinced we actually need more, that's why I ask for
use cases.


View raw message