ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [RFE] Richer Task Specification
Date Fri, 23 Jun 2000 13:36:23 GMT

.duncan wrote:
> I'll go for pure as long as it can be explained in a parapgraph of good
> docs. I'm hesitant to go for expediency. It's a fine line obviously. :)

I wasn't arguing for expediency.  Purity is in the eye of the beholder.

Since all you guys have been seeing is a paragraph here or there, let me
take a moment to attempt to present a more coherent world view.  I'm not
saying that this is the only valid world view, but simply a coherent means
to addressing the problem.

 - - -

I've been studying scripting languages.  These are popular in a number of
contexts.  One of the reasons for their popularity is that they are
approachable - one can typically get started in a manner of minutes.
Features that you don't need to know don't get in your way.  Simple hello
world programs are typically one line, generally something along the line

   print "hello world!"

Contrast this with Java.  Java is "purer" because everything is an object.
There are predefined methods (like main) which are understood by the system
but aren't explicit (quick - can you find where this is documented?  I'm
sure you can, but you shouldn't have to).  You not only need to understand
object orientation, but also public scoping, and words which we have all
come to accept but have non-intuitive meaning, like "static" and "void".
Finally, you also have to be prepared to accept an array of arguments that
you don't need.

Note: please return your flame throwers to their holsters.  I'm a big fan
of Java - particularly when your intent is to write objects.  Back to Ant.

In Ant's case, the "start simple, grow fast" approach would be to simply
state that a project can be as simple as a list of tasks.  These tasks are
executed in the order listed, and in general are smart enough to do "the
right thing".  This smartness eliminates the need present in competitive
build systems (read: make) to explicitly state such things as to only
compile the output if it is newer than the input.

As your needs change, if you find yourself desiring the ability to arrange
tasks into groups and letting the system determine the order, this is
easily accomplished by introducing targets and dependencies.  Targets
introduce the ability to put other than a sequential ordering to tasks, but
tasks contained within a target are executed sequentially, as you would

There are other "containers" being explored: async and system come to mind.
I have yet to see a suggestion that every task must be embedded in an
"async" element, in order to capture the desired the synchronicisity of the
tasks contained within, or anybody worrying about the fact that the same
tasks can be used both inside and outside of async elements.

My feeling is that all of these concepts should not get in your way if you
don't have need for them..  If you do, they will be available and build
gently upon what you have already learned.

- Sam Ruby

View raw message