ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Parameterized "task-function"
Date Mon, 15 Jan 2001 07:29:29 GMT
At 02:10  15/1/01 -0500, Jason Rosenberg wrote:
>XSLT issues aside, do you agree or not that opening up all the internals
>of Ant via the <script> task, as is currently the case, is a serious problem?

I do now - someone convinced me that we don't/may not even really allow
such things in Ant2.0 - don't know it was never decided.
>With regards to XSLT, I don't think you should use 'XSLT' and
>'good build files' in the same sentence.


>> >2. direct calling of targets, e.g. <call-target> (not antcall!),
>> >    with parameterized arguments passed to the target.
>> will be in Ant2.0
>Hadn't heard that, in fact it certainly seems like you've been on
>my case when I've suggested the need for this.  Perhaps it was
>someone else....

Well it is Ant1.x and it is implemented in at least my proposal for Ant2.0.
In general it is of limited usefulness thou there are some cases that it
does become useful. I don't object to it - I object to
if/then/else/case/whatever tasks ;)

>> >3. tasks then, need to be dynamically reusable and reconfigurable,
>> >    so that when they are traversed as part of call-target, they
>> >    represent fresh instantiations of the task, so that new filesets,
>> >    etc., can be attached to them.
>> will be in Ant2.0
>My god, Ant2.0 is getting more procedural and less declarative
>every day.

ummm ... you should really go read up on what is declarative/procedural
distinction. This actually makes it more declarative ;)

>> >4. more functional boolean logic conditions, with the ability to
>> >    call a target directly based on the evaluation.  And I am
>> >    in favor of the boolean logic being expressed in an xml
>> >    like structure, instead of cryptic C like expressions.  Need
>> >    else functionality too, and possibly case, etc.
>> will have better boolean testing in attributes like if/unless and available
>> but unlikely to have if tasks in Ant2.0.
>Too procedural, huh?

essentially - that would turn ant into a scripting language. Not something
that will happen. (at least not for build files).

>> >5. ability to conditionally gate execution of a target before 
>> >    evaluating dependencies, as well as after.  Currently,
>> >    you can only do so after, using  the if/unless syntax.
>> can you think of a good way of doing this without an extra attribute.
>> Currently I do this by wrapping it in ant-call
>> ie
>> <target name="..." if="precondition">
>>   <antcall target="mytarget" />
>> </target>
>> <target name="mytarget" if="postcondition" depends="...">
>> ...
>> </target>
>Yeah, you can do that with antcall, but the whole issue has been that
>antcall has a whole bunch of other problems, that make it an unintuitive
>solution for what it is I am asking for.  


>When you call mytarget, any
>state it might set will be lost once the antcall finishes, which makes it
>appear that it never occurred to the rest of the processing of the ant

Fixed in the myrmidon proposal - it is even very performance sensitive.

>> >6. simple iteration loops, i'd be happy only with a while loop,
>> >    which could be implemented very easily (it is essentially
>> >    a simple goto back to start on condition construct).
>> will never occur - more likely to build simple declarative structure with
>> XSLT which has looping/iteration/whatever
>Is XSLT really so wonderful?  

no ;)

>Why not have a simple, intuitive task
>for a loop, much in the vein of everything else that is intuitive and
>straightforward about Ant.  The intuitive feel will be lost when
>you start going the xslt route:

perhaps - but if we include whiles then next will be if, then do/while,
then for, then for-each etc. XSLT already does all this and we don't want
to reinvent the wheel. XSLT is standard and much more powerful - and
besides we don't have to do anymuch work to get it going.

><while property="myprop">
>    ....
>Doesn't look too complicated to me, in fact, it's simple and intuitive.
>Dare I say, "it's declarative!".  How do you specify iteration in a
>declarative manner, anyway?

You generally can not specify iteration as such. You can specify an
operation on a set of classes thou or sequence.

So in pseudo SQL it would be something like

doOperation( select * from Foo );

>Personally, I think if we are going to be purists here, we need to
>get rid of both <script> and <antcall>.  And once you do that,
>inevitably you will have to cave to the proceduralist pressures.

>But by allowing <script>, you are attempting to hide your head
>in the sand "It's not procedural, really, but gee, if you really need
>it, you can use javascript via <script>".

actually - i don't think script will be able interact with object model (or
at least I no longer see any good reason to allow it) - it will be more
useful for ad-hoc operations. Like calculating the value of PI times
current day divided by the phase of the moon ;)

>> >You are trying to say that Ant is just a language for declaring
>> >a bunch of build data.
>> Nope ants build.xml format is a declarative form for describing a build
>> process.
>Pardon me?  Ant's build.xml is a "declarative form", but "nope" it's
>not a "language for declaring ...".  Splittiing semantic hairs, are
>we not?




| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message