ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <>
Subject What flavour of scripting?
Date Tue, 29 Feb 2000 05:26:58 GMT
Hi again,  :)

Sam Ruby's wrote:

> It is worth noting that conditional logic was recently introduced into Ant
> to support cocoon.
> I recognize that this is clearly the beginning of a very slippery slope.
> Unfortunately, I don't believe that the right position to take on this
> issue is that such logic doesn't belong in Ant and that Cocoon should
> write their own taskdef for this case.  In this case, the logic clearly
> belongs in Ant.  Nor do I believe that Cocoon's build needs are unique in
> this case.
> In the theory that it is never too late, let's take the opportunity now to
> go back and answer Stefano's question.

I assume this question was along the lines of: What is the best way to add
logic/scripting to Ant?

Costin wrote:
> I feel that every feature we add on this direction is a step in the wrong
> direction, and makes ant more complex. And I'm afraid we'll end up with a
> xml-make. 

Why do you see this as bad?  What are the symptoms of it "being the monster
it is today"?

I've already posted my pet peeves with make: Symbol soup,
non-cross-platform, non-guiable.

The main thing I've heard you mention is that you want to be able to
machine process the build file.  Are there any others?  Is this a lost
cause?  Is there a half-way point?

Costin also wrote:
> I am also very much against using XML as a programming language.
> <foreach>, <if> are ( IMHO) one of the worst way to write programms. I
> know everyone will disagree, but that's my opinion - XML shouldn't be
> used as a programming language.  
> I would agree with your proposal if you choose any existing language (
> except Basic ) and use it to script ant tasks. I think it is a good idea
> to do that.

In general I agree that XML is not a good starting point for a scripting

How is this for a suggestion:  we have a task that calls BeanShell
<> (chosen because I know it exists, it is very
close to java making it easy to learn, and is cross-platform.  Other
suggestions welcome.).  The beanscript can have embedded XML tags, tasks,
that get called when they are reached.

For this to work, you still need to be able to embed tasks within tasks.
The difference is that you use that capability to write a <script> task
instead of a <ForEach /> task.

Along this line of thinking we could use any number of scripting languages.
e.g. <>  We could also remove the need for a
<script> tag by specifying that any text in a target is interpreted by a
particular interpreter (not sure if I actually like this script-in-target

Adding a specific scripting language has a number of advantages:
 - You don't script in XML.
 - You can still script.
 - You get someone else to maintain the scripting language :).

It also has some disadvantages:
 - You have to move from XML to a scripting language for even the simplest
 - We have to pick a scripting language and then learn ANOTHER language.
 - Any use of the scripting language is going to break whatever
machine-processesing of the buildfile you wanted to do.

  There are a large number of cases where an XML <switch> is going to be
better than jumping into a scripting language.  This is because you don't
have to change languages.


\x/ill         :-}

View raw message