ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <>
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 06:28:48 GMT
-- Jose Alberto Fernandez <> wrote:
> William Uther wrote:
>> -- Jose Alberto Fernandez <> wrote:
>> > I like the idea of allowing other languages besides Java. It opens
>> > things up. I do not think we should treat scripting languages in any
>> > special way. For that I propose just extend <taskdef ...> to allow for
>> > other languajes.
>>   (1) You lose the ability to easily place Ant tasks in the scripts.
> This I do not understand. What ability is that we are loosing?
> You still can use any tasks you want.

The ability to do something like:

<script langauge="exampleScript">
	for heaven = 1 to 7 do
		<knockOnGate type="pearly"/>

(Is a religous example fitting for this debate? :)

You can have the task embedded in the script.  As the script tag is parsed,
the text would be sent to an addText method, the tag to an addTask method
which would presumably add something into the script that allows the script
to execute the task at an appropriate time.

If you move the script into an entirely separate file then you lose the
ability to call the current array of tasks easily.  You'd have to call out
to java, setting up the appropriate context, etc.  Depending upon the
scipting language this may or may not be easy to do.  You could write some
library functions to make this easy.  I don't think it's worth it.

(I can hear people thinking "Why do you want to embed Ant tasks back into
the scripting langauge?"  To which I reply:  that's the point.  If you
can't do that then you may as well just stick with java tasks.)

I must admit I don't find the above particularly pretty, but people seem to
prefer it to:

<ForEach name="heaven" list="1;2;3;4;5;6;7">
	<knockOnGate type="pearly"/>

(another definition of simpler for those keeping track: doesn't intermingle
two languages.)

Here is my rationale for scripting in Ant (this was brought on by looking
at the above examples):

There Is A Gap.

  You want the difficulty of scripting something to be somewhat
proportional to the complexity of what you're trying to do, weighted by how
often you do it.

  At the moment, linear composition of Tasks is very easy to do.  For build
logic with any significant complexity you are best off going to java and
writing a new Task.  However, there is a gap at the level of simple
conditional and looping code.  Build logic commonly requires this level of
complexity - this sort of thing needs to be made simpler than writing a new
Task.  e.g.  Some Apache projects already require conditionals.  Switching
based on the OS should not be rocket-science.

You Can Close The Gap In Three Ways.

  The gap could be closed in a few ways.  You can add simple looping and
conditionals to the XML.  You can add another scripting language.  You can
make writing Tasks easier.

  It should be possible to move down the top end of the gap with a few nice
support libraries for Task writers (ability to call other Tasks easily from
java, etc).  That means that the gap is actually fairly small.  If it
wasn't hit so frequently (Of the three projects I'm working with now, two
of them could do with a ForEach, and one with a switch) then I would just
ignore it and agree that writing java Tasks was the way to go.

Adding A Scripting Language Is Overkill.

  Adding a full scripting language does give us a well-designed general
purpose scripting language.  This is good as far as it goes.
Unfortunately, it also gives people who want to write complex build logic
two choices: do it in the scripting language or write a new Task.  This is
going to lead to people writing complex stuff in the scripting language
instead of new java Tasks.

  I would prefer a solution so simple that it DOESN'T scale well.  It
should become unwieldy long before it becomes incomprehensable at a quick
read.  It should close the gap and not much more.  That way people are
forced to move to java and write Tasks for complex code.

  For instance, I think functions are an awful idea.  They are used for
code that is either complex, or reused often.  These are exactly the sort
of things that should be put in a Task.  Similarly, having a language as
powerful as python (I've never really used javascript, so I can't comment
there) is going to tempt people to put too much logic in the build file
instead of in the Tasks.  This could well make Ant into a monster.

  Given that this scripting language should only be used for relativly
simple purposes, it should also be relativly easy to use.  Introducing a
full 'scripting language' is going to be more difficult to use than I would
like, simply because you will have two different languages in the same file.

Adding A Few XML Tags Can Close The Gap Without Going Too Far.

  Adding a few XML tags can close the gap without going too far. :)  I
don't think there is a problem defining detailed semantics here.  There
would be no functions and hence no recursion.  For variables we already
have the property mechanism (assuming it is fixed, either one way or the
other), and I would argue against local properties.  Neither <switch> nor
<foreach> is particularly complex.  This extension may be turing complete,
but it still leaves Basic looking complex.

  The only problem I can see with this is the religous one: THOU SHALT NOT
PUT LOGIC IN XML.  While I agree with this in general, in this case I
prefer it to the alternatives.

  In summary, I think there is a gap that gets hit frequently.  I think it
can be closed with changes at either end.  The other solution is to
introduce a scripting language to fill the gap.  This is going to overlap
at the top end with traditional java tasks.  The overlap is also going to
make it too easy for people to cram too much complex logic into the

sigh - that was longer and more soap-boxy that I thought it would be when I
started :).

> Which brings a good point, how
> one guarantees the the correct task classes are available to ANT when you
> run it?
> I think we will need a way to specify jars containing the code necessary:
>   <tasklib name="xyz" jar="....." dir="....">
>   <taskdef name="mycopy" tasklib="xyz" classname="....">
> This will allow to separate user-provided tasks from core. The <tasklib>'s
> atributes can define a jar (JAR file containing the runtime for some
> tasks) and/or
> dir (a directory location containing the runtime).

Which is what I suggested in the thread "Re: <taskdef /> extension
mechanism".  (Although I suggested a "classpath" attribute whereas you have
a "jar" attribute.  I was also wanting it for normal java tasks, not plugin
scripting languages.)


\x/ill           :-}

View raw message