ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg" <ja...@squaretrade.com>
Subject Re: Parameterized "task-function"
Date Mon, 15 Jan 2001 07:10:27 GMT

----- Original Message ----- 
From: "Peter Donald" <donaldp@apache.org>
To: <ant-user@jakarta.apache.org>
Cc: <ant-user@jakarta.apache.org>; <ant-dev@jakarta.apache.org>
Sent: Sunday, January 14, 2001 9:58 PM
Subject: Re: Parameterized "task-function"


> At 02:56  12/1/01 -0500, Jason Rosenberg wrote:
> >This is a very dangerous precedent, though, since by having the
> ><script> task, you are inviting lots of backwards compatibility
> >complaints in the future.
> 
> I don't see anything in you desription that can't be done with xslt/good
> build files.
> 

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?

With regards to XSLT, I don't think you should use 'XSLT' and
'good build files' in the same sentence.

> >1. resettable property values.
> 
> will be in Ant2.0
> 

So I've heard.

> >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....

> >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.

> >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?

> >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
project.

> 
> >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?  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:

<while property="myprop">
    ....
</while>

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?

> >7. improved logging, don't need every target visited reported
> >    to the output, etc.  Perhaps just need a -antsilent flag,
> >    which suppresses all but explicitly defined task specific output, etc.
> 
> agreed.
> 
> >The bottom line.  Ant is and should be a scripting language.  When
> >you try to say it isn't, you force people down the <script> route,
> >as the only recourse, which is nothing but a can of worms.
> 
> nope.
> 

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>".

> >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?

Jason




Mime
View raw message