ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: What flavour of scripting?
Date Tue, 29 Feb 2000 13:15:39 GMT
William Uther wrote:
> 
> Hi again,  :)
> 
> Sam Ruby's wrote:
> 
> > It is worth noting that conditional logic was recently introduced into Ant
> > to support cocoon.
> [snip]
> > 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.
> [snip]
> > 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?

Considering that the scripting guru we have on this list (in case you
didn't know, Sam is responsible of the ECMAScript specification process
and author of BSF, a framework that adds hooks between java and tons of
scripting languages) I would like to hear him :)

But I have something to say myself: Sam is right, I needed something
that worked. And I wrote something that worked without requiring any
modification to the Ant core. Plain and simple.

Now: if you don't like the solution and have something better... great.
I asked before doing it and nobody answered.

So, again, I think Cocoon's needs are general: if a class is not present
don't try to compile parts of the program that rely on it. It make the
Cocoon build file more complex but it resulted into a _very_ powerful
build system. Probably something that even "make" could hardly match.

What I ask is not to remove such thing... I don't mind rewriting the
build file even ten times, but we need some conditional execution of
targets/tasks.

But Costin is right: there is a big difference between <switch> or <if>
and the attribute if="": elements define tasks, tasks SHOULD NOT be
programming tokens. Attributes are what the word says: the attribute
some behavior to the task that includes them.

We could use the ant: namespaces for programmatic attributes something
like

 <task ant:if="...">

or simply don't care and do like Sam's proposal:

 <task unless="...">

But, please, let's forget about <switch> <for> and <if> and let's do
something equivalent in functionality but without ruining the simplicity
of the approach.

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

When you can't create your makefile by examples. This is the ultimate
definition of a monster language. This is also why I don't like hidden
things (like the hidden call to the init task): you can't tell without
reading the docs.

Do you understand why HTML was such a powerful language? How long did it
took you to write your first HTML page by looking at somebody else's? 10
seconds?

How long did it took you to write your first makefile after looking at
somebody else's? much longer.

The final goal: provide enough flexibility inside Ant to do everything
that is required inside the apache projects. If we can match that
building complexity, everything else is plain simple.

But the constraint is: one should be able to clone their build file from
mine in less than 10 minutes and possibly without looking at the
documentation. If this is not possible, we did a mistake, but if we use
this as our quality meter, we can go back and fix this.

Usability is a feature. Lack of usability is a bug. It's about time to
enforce this with every possible mean and I know that almost all the
people on this project have my same vision.

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

Yes, these are part of the problem, but not the problem itself. Ant is
using the same exact simbols that make is using and make is probably
more cross platform than ant (gnu tools have been ported to all existing
operating systems, this is not the case for java).

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

Sorry, I'm not following you here.
 
> 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
> language.
> 
> How is this for a suggestion:  we have a task that calls BeanShell
> <http://www.beanshell.org/> (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.

This is better, but adds unnecessary (IMO) complexity to the build file.

Remember, I should be able to clone your build file without looking at
docs. If I don't know your scripting language, this is not possible.
 
> Along this line of thinking we could use any number of scripting languages.
> e.g. <http://www.jpython.org/>  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
> idea).

Sam, you're the expert here, what are your thoughts on this?
 
> 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 :).

This is a better approach, I agree. Still I don't see the need for such
power.
 
> It also has some disadvantages:
>  - You have to move from XML to a scripting language for even the simplest
> things.
>  - 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.

These are nasty disadvantages IMO... they create more problems than they
solve.
 
>   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.

I agree we need some conditionals and interations. Just let's find a way
not to use elements for this and not adding some dangerous path to
unnecessary complexity.

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



Mime
View raw message