You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by William Uther <wi...@cs.cmu.edu> on 2000/02/29 06:26:58 UTC
What flavour of scripting?
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?
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
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.
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).
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
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.
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.
later,
\x/ill :-}
Re: What flavour of scripting?
Posted by Jayme Edwards <an...@execpc.com>.
Actually, you could use the xlink for this purpose. With X-link, you can
reference external elements whether they are in that file or not. e.g:
/build.xml
<project name="myProject"
xlink:title="My Project"
xlink:type="extended"
xlink:role="project"
xmlns:xlink="http://www.w3.org/1999/xlink">
<target name="compileRemote"
xlink:title="Compile Remote Source"
xlink:type="locator"
<!--this file would have <target as the docelem>
xlink:href="somerelpath/somesubdir/somefile.xml"
xlink:role="target"/>
<target name="compileLocal">
<javac ... etc/>
</target>
</project>
/somerelpath/somesubdir/somefile.xml
<?xml version="1.0"?>
<target name="compileRemote">
<javac ... etc/>
</target>
I'm using this in a project running on Tomcat right now with a stylesheet
that can replace the linked elements with the content and/or produce
hyperlinks to the target doc in HTML.
Jayme Edwards
Rockwell Software
Control Studio >>
[ http://www.openautomation.com/controlpak ]
----- Original Message -----
From: David Bullock
To: ant-dev@jakarta.apache.org
Sent: Monday, February 28, 2000 11:46 PM
Subject: Re: What flavour of scripting?
Perhaps jamming it all into one build configuration file is the issue. XML
is a natural candidate for building a Dependency Markup Language. But
building a software project is not all dependency management (hence the
'actions' concept of Ant). The actions to take in response to dependency
triggers could probably be best specified in some kind of scripting
language. (On the topic of "which scripting language?", JPython has a
natural mapping to Java OO programming, but it is still another language to
learn(!))
What about a build.dml file to specify the dependencies, and another file
(build.jp ?) to describe what to do about the dependencies. I'm new to
unixland, and haven't ever made my own Makefile, but isn't the idea that you
specify the dependencies (if x.java has changed, then rebuild xyz.jar ...
not to mention the interdependencies between classes, packages etc.)? The
current task metaphor of Ant seems to promote a more procedural, switching
kind of approach to building a project. Which is probably not what we want.
Regards,
David.
PS
> 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?
Stefano's original question was:
----------------begin quote-------
ant is a great tool, but it's based on make design patterns. Read:
targets and tasks.
Now, in Cocoon, I would like to have a target executed if and only if a
particular condition is true.
This condition might well be:
- a property set (example: do a snapshot or a release distribution)
- the existance of a class in the classpath (example: a pluggable
module requires JNDI but the JNDI classes are not found)
- time
- operating system
Question: how do we do this?
Constrain: I need this done _soon_ in order to build the new Cocoon
distribution and I'm volunteering to write any required changes once we
agree on _how_ a feature like this should be done.
comments?
----------------end quote----------
--
David Bullock
Project Leader
dbullock@lisa.com.au
"It's no use saying 'We are doing our best.' You
have got to succeed in doing what's necessary."
...Winston Churchill
LISAcorp
http://www.lisa.com.au/
Adelaide Sydney
-------------------- ------------------------
38 Greenhill Rd Level 3, 228 Pitt Street
Wayville S.A. 5034 Sydney NSW 2000
PH +61 8 8272 1555 PH +61 2 9283 0877
FAX +61 8 8271 1199 FAX +61 2 9283 0866
-------------------- ------------------------
Re: What flavour of scripting? [XML modelling thread]
Posted by David Bullock <db...@lisa.com.au>.
Ludovic Claude wrote:
> > What about a build.dml file to specify the dependencies, and another
> > file (build.jp ?) to describe what to do about the dependencies. I'm
> > new to unixland, and haven't ever made my own[...]
>
> Two build files to compile one project now?
or two sections:
<dependency-group>
<state name="d1"/>
<state name="d2"/>
<depends>
<source states="d1">
<target states="d2">
<action-ref name="actionID">
</depends>
</dependency-group>
<actions>
<action name="actionID">
<script lang="jpython">
script goes here
</script>
</action>
</actions>
....all in the same XML file.
??
--
David Bullock
Project Leader
dbullock@lisa.com.au
"It's no use saying 'We are doing our best.' You
have got to succeed in doing what's necessary."
...Winston Churchill
LISAcorp
http://www.lisa.com.au/
Adelaide Sydney
-------------------- ------------------------
38 Greenhill Rd Level 3, 228 Pitt Street
Wayville S.A. 5034 Sydney NSW 2000
PH +61 8 8272 1555 PH +61 2 9283 0877
FAX +61 8 8271 1199 FAX +61 2 9283 0866
-------------------- ------------------------
Re: What flavour of scripting?
Posted by Ludovic Claude <lc...@websitewatchers.com>.
David Bullock wrote:
> Perhaps jamming it all into one build configuration file is the
> issue. XML is a natural candidate for building a Dependency Markup
> Language. But building a software project is not all dependency
> management (hence the 'actions' concept of Ant). The actions to take
> in response to dependency triggers could probably be best specified in
> some kind of scripting language. (On the topic of "which scripting
> language?", JPython has a natural mapping to Java OO programming, but
> it is still another language to learn(!))
>
People using Ant are JAVA developers, with a beginner experience of xml.
Python, lisp, tcl/tck, i've heared of them, i've used lisp once in my
school years, but i don't
want to learn/use them.
>
> What about a build.dml file to specify the dependencies, and another
> file (build.jp ?) to describe what to do about the dependencies. I'm
> new to unixland, and haven't ever made my own[...]
Two build files to compile one project now?
Ludovic.
--
_____________________________________
Web Site Watchers Ltd
212 Piccadilly,
London W1V 9LD
United-Kingdom
Telephone: +44 (0)171 917 6255
Fax: +44 (0)171 439 0262
http://www.websitewatchers.co.uk
lc@websitewatchers.com
Re: What flavour of scripting?
Posted by David Bullock <db...@lisa.com.au>.
Perhaps jamming it all into one build configuration file is the issue. XML is
a natural candidate for building a Dependency Markup Language. But building a
software project is not all dependency management (hence the 'actions' concept
of Ant). The actions to take in response to dependency triggers could probably
be best specified in some kind of scripting language. (On the topic of "which
scripting language?", JPython has a natural mapping to Java OO programming, but
it is still another language to learn(!))
What about a build.dml file to specify the dependencies, and another file
(build.jp ?) to describe what to do about the dependencies. I'm new to
unixland, and haven't ever made my own Makefile, but isn't the idea that you
specify the dependencies (if x.java has changed, then rebuild xyz.jar ... not
to mention the interdependencies between classes, packages etc.)? The current
task metaphor of Ant seems to promote a more procedural, switching kind of
approach to building a project. Which is probably not what we want.
Regards,
David.
PS
> > 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?
Stefano's original question was:
----------------begin quote-------
ant is a great tool, but it's based on make design patterns. Read:
targets and tasks.
Now, in Cocoon, I would like to have a target executed if and only if a
particular condition is true.
This condition might well be:
- a property set (example: do a snapshot or a release distribution)
- the existance of a class in the classpath (example: a pluggable
module requires JNDI but the JNDI classes are not found)
- time
- operating system
Question: how do we do this?
Constrain: I need this done _soon_ in order to build the new Cocoon
distribution and I'm volunteering to write any required changes once we
agree on _how_ a feature like this should be done.
comments?
----------------end quote----------
--
David Bullock
Project Leader
dbullock@lisa.com.au
"It's no use saying 'We are doing our best.' You
have got to succeed in doing what's necessary."
...Winston Churchill
LISAcorp
http://www.lisa.com.au/
Adelaide Sydney
-------------------- ------------------------
38 Greenhill Rd Level 3, 228 Pitt Street
Wayville S.A. 5034 Sydney NSW 2000
PH +61 8 8272 1555 PH +61 2 9283 0877
FAX +61 8 8271 1199 FAX +61 2 9283 0866
-------------------- ------------------------
Re: What flavour of scripting?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------