I've tried looking back through the posts to clarify this one, but haven't found a
reference.
Jason, you mention that Ant isn't a scripting language, but don't explain why. I
presume this is because there is an explanation somewhere of the argument for it not
being a scripting language. Could you possibly refer me to it, or post it to me.
In the absence of an explanation, I can guess that there are good reasons why Ant does
not want to become the start of another alternative to JavaScript or shell scripts or
whatever, simply on the basis that duplication is going to dilute the effort going
into making any one tool the best of class.
However, I can also see, and appreciate from my own experience of using ant, that
there are times when some basic 'scripting' functionality would go a long way to
making scripts easier to write and maintain. To give a simple example (which I don't
think can be dealt with by ant at present):
My standard development ant script compile and runs junit tests every time. During
development I want to be able to view the output to console, so I want the junit
option of saving to a file to be set to "no". When it comes to the final distribution
I have a "dist" target which compiles, builds, tests and packages. However, this time
I save the tests to file and include in the package as a permanent record of test
success and timings. This requires the exact same test target, but with the save to
file option set to "yes". Currently the only way I can see of doing this is to have
two different test targets: "testAndDisplay" and "testAndSave". It would be a lot
easier to maintain if these could be a single task that would accept a parameter.
...just a few of my thoughts for the discussion.
Stuart.
On Monday, January 15, 2001, at 07:21 AM, Jason Rosenberg wrote:
> On 1/10/01 10:48 PM, "Jason Rosenberg" <[EMAIL PROTECTED]> wrote:
> > Ant is not a scripting language. Saying it a few thousand times won't make
> > it so. If you want to build a build system around a scripting language (my
> > suggestion: JavaScript using the Rhino engine), then by all means do it.
> > Scratch your itch. But don't keep trying to make Ant something it is not.
> >
>
> I didn't really want to design a build system based on JavaScript using
> Rhino, but was left with no choice but to do so. But I did so
> within Ant!
>
> If Ant is a complete model, I suggest you get rid of the <script> task
> altogether, and use other means to satisfy the demand for what <script>
> provides. Otherwise, I don't think you can safely argue this issue
> from any sort of purist's standpoint. You may even conclude that what
> <script> provides should not even be attempted, in which case you have
> even more reason to remove <script>.
>
> Ant is just short of about 2 or 3 procedural tasks, and it will really
> be ideal. It is so close and so intuitive, for which you should be
> proud. I have no interest in dropping it and doing something else.
>
> What I want is Ant without:
>
> <script>
> <antcall>
> <!ENTITY>
> XSLT
>
> and Ant with:
>
> <execute-task>
> <if/else>
> <while>
> <include>
> and the new features promised for Ant2.0 (resettable properties!)
>
> I'll probably end up doing these tasks myself, which is easy enough,
> but I have to believe they should be included in the builtin tasks.
>
> I'm a believer in Ant, it is what I want. I apologize if it irks you and
> the other creators to see your hard-worked blasphemed in such
> a way, but sometimes as creators you have set your creation free.
>
> Jason
>
>
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS http://www.adolos.com/
