ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From be...@netscape.com (Patrick Beard)
Subject Re: Role of scripts [was Re: increment task]
Date Wed, 25 Oct 2000 21:46:30 GMT
At 2:07 PM -0700 10/25/00, Louis Tribble wrote:
>My 2 cents: script tasks are great; but I would hate to see support for
>common build needs pushed out of Ant just because a script task can do
>it. If common build setups require using scripts, then two of Ant's
>major strengths, simplicity of _use_ and portability, have been
>compromised:
>
>Simplicity of use*, because if the build instructions for typical
>projects begin with "install Ant _and_ scripting app XYZ", even
>installing isn't so simple. Needing to learn yet another language just
>to understand the build file makes it even less simple. I'd really
>rather go read a real Ant task: I already know Java.

I believe that a scripting language should always be available as 
part of an Ant installation. I package ant as a single binary file, 
ant.jxe, which is an executable for JShell 
(http://www.vmeng.com/beard/JShell). I include BSF, and Rhino as part 
of the ant executable, so for JShell users, Rhino JavaScript will 
always be available.

>Portability, because a build file that requires scripting is only as
>portable as the scripting application.

Rhino is 100% pure Java, runs on JDK 1.1 and later, and even compiles 
JavaScript code into Java bytecodes, so it performs very well.

>I'd argue that projects that really want the simplicity and
>portability benefits of Ant should not use scripting. If they
>need something that Ant doesn't support, they should provide
>an appropriate Ant task. For common requirements, it would be
>a shame not to provide a standard task, or at least a standard
>"optional" task.

So you think providing a way to find the optional task is easier to 
do portably than to just bundle a scripting implementation into Ant 
itself? The advantage of scripts is that they don't require the 
compile/debug cycle that standard Java code requires, so the barrier 
of entry is lower. And, the flexibility of scripts means that I can 
define my own tasks, perhaps even sub-class internal tasks and tweak 
things to be exactly the way my build system needs. Being able to 
extend Ant's capabilities using Java is certainly a great thing, but 
having that be the only extension mechanism is limiting.

- Patrick
-- 

// Patrick C. Beard
// Java Runtime Enthusiast -- "Will invoke interfaces for food."
// mailto:beard@netscape.com

Mime
View raw message