ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 11:07:13 GMT wrote:

> At this point you might be wondering why I am bringing this up.
> First, I'd like to ask that you and others not to be so quick to prejudge
> the conceptual cost (both in implementation and usage) associated with
> various proposals.

I'll try to be neutral about proposals. Read: let's not get religious on
> Second, and more importantly, I am going to continue to try to steer this
> conversation towards requirements.  Please, everybody, tell me WHAT you are
> trying and WHY what you are proposing is the simplest solution to your
> problem.  Abstract examples with foos and pearly gates just don't do it for
> me.

Very correct.

My requirements (constraints):

1) One should be able to understand the build.xml without looking at the
documentation. There are a couple of things that break this pattern:

 - tstamp -> you don't know what variables are set unless you look into
the docs.
 - the proposed .antrc -> win32 people are _NOT_ used to such pattern

Interesting enough, Costin doesn't seem to like my visibility pattern :)
probably he's used to man and not to the win32 help system. Lucky boy.

2) I need conditional execution on collection of tasks depending on
environmental parameters such as class presence, property presence.
Condition on property value is not required at this moment, but I do
picture a need for this.

3) I would like to have two different set of tasks:

 - external tasks: these are the tasks that "do something" exterally to
 - internal tasks: these do not change the environment _outside_ Ant,
but change it's internal state or its internal behavior.

For now, these are the internal tasks:

 - Project
 - Target
 - Property
 - Available
 - Filter
 - TStamp

I propose to use a different namespace for them, this would help both
visual GUI tools and people to understand their different behavior.

I would also like these internal tasks to behave OO-like: each target
inherits all the tasks it depends to (both external and internal), but
if an internal task is present and has the same "effect", it should
change the internal state and overwrite the previous state.

4) I do not care about iterative internal tasks since I wouldn't use
them. And, IMO, they do not belong at this level but inside the external
task logic.

Gone preparing the asbesto shield :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message