ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 10:19:49 GMT


Pier wrote:
> Ok, I won't continuing debating that since how Ant works right now is
> more than fine (so I can just forget to update it in the future) but,
> really, ARE YOU SERIOUS about that?
> Because if so, I'll just get my Jar and let you people deal with it any
> further... You're really adding an ELEPH in front of the ANT...

Bye,  Pier!  ;-)

Seriously...in the not too distant past, nested tags were thought to add
incredible complexity to the implementation, or make ant more difficult to
learn and use. Thankfully, we were wrong.  If you care to, take a look at
processNestedProperties in ProjectHelper, and at MatchingTask.

Then take a look at cocoon's current build.xml.  Via dependencies, the
prepare-src target is essentially composed of a series of optional tasks
which copy selected portions of the java code to a separate directory tree,
and the compile task will compile that separate tree into a third location.
I guess that this is OK when there are only three optional subsystems, but
take a look at what needs to be done if a fourth subsystem is added - an
<available> task will need to be added, a complete new target with a
copydir task will need to be added.  The dependencies on prepare-src will
need to add this target.  Finally, another exclude will need to be added to
the copydir task inside of prepare-src itself.

BSF currently has support for over a dozen optional scripting languages.
My feeling is that the approach described above doesn't scale well.

With nested tags, one can directly add
   <include name="**/javascript/**" if="javascript.present">
or, conversely,
   <exclude name="**/javascript/**" unless="javascript.present">

I feel that this is significant improvement.  The scripts are smaller,
easier to understand, and easier to modify.

One still needs to code an <available> task.  Actually, in my original
implementation, I hadn't taken the time to understand what Stefano had
added, so on coded the class you were looking for directly on the include
or exclude element, but I have now changed it to be more consistent.
Besides, I find that explicitly naming the variable gives an opportunity
for the script to become more understandable.

At this point you might be wondering why I am bringing this up.

First, I'd like to ask that you and others not to be so quick to prejudge
the conceptual cost (both in implementation and usage) associated with
various proposals.

Second, and more importantly, I am going to continue to try to steer this
conversation towards requirements.  Please, everybody, tell me WHAT you are
trying and WHY what you are proposing is the simplest solution to your
problem.  Abstract examples with foos and pearly gates just don't do it for
me.



- Sam Ruby



Mime
View raw message