ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 18:30:38 GMT
--On Wed, Mar 1, 2000 5:19 AM -0500 rubys@us.ibm.com wrote:

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

Ok,

Requirements:

  I have three projects I'm working on at the moment.  Two of them have OS
dependancies.  I'd like to be able to turn things on and off based on the
OS I'm running on.  This is more than just testing for the existance of a
property (os.name exists on every JVM), I want to check the value of a
property.  This is more a switch-style "choose among alternatives" than an
if-style "should I execute this one" conditional.

  The other thing I'd like to be able to do is to build a number of
sub-projects.  I'd prefer it if Ant could build every subproject in a
directory instead of forcing me to list all the subprojects in the build
file (this is an extdirs vs. classpath type preference).

  I strongly agree with Stefano:
> 1) One should be able to understand the build.xml without looking at the
> documentation.

  I would like the solution to be cross platform.  It should go nowhere
near Runtime.exec().  If it is going to use an external scripting language
then there should be a java runtime for that language.  (Otherwise I'm not
going to be able to use it.)

Design thoughts:  (These are preferences, not requirements, and are less
empirically supportable)

I believe in the KISS principle.  Here are some thoughts on how it applies
in this case:

  - I'd like to avoid a large conceptual leap jumping back and forth
between the control logic and the XML.
  - Arguments should contain information directly relevant to that tag.
  - The control constructs in the XML file should be simple enough that
programmers avoid them for complex logic and write Tasks instead.

Proposed solutions:

First the iteration:  This could be fixed with either a looping construct
or by modifying the Ant task to use includes="" instead of dir="" or
antfile="".  I would have done this modification to the Ant task already,
but I'm wary of coding anything up until the current discussions are sorted
out.

Next the conditional:  I do not see control logic as directly relevant to
most of the current batch of tasks.  I would prefer to have control logic
in separate tags than in the arguments to tasks.  This will separate the
control from the action itself and also help keep the argument namespace
cleaner.  If people want to put conditionals in the arguments then I'd
suggest it go into the target arguments (like Stefano's current solution)
rather than the the task aguments (as people seem to be discussing).  This
way the extra arguments don't have to be handled by every Task implementor.

In both these cases, I think introducing a new scripting language is
overkill and could easily lead to a 'discontinuity' between the XML and the
scripting language.

Finally the library:  I think it should be easier to write tasks for Ant
that call other tasks.  It may be that all this requires is good
documentation.  Documenting Project.createTask() and a few other methods
(possibly Project.setProperty()) would be good.  Separating property tasks
from execution tasks would also help here because it would simplify the
interface to execution tasks.  Finally, I think we should modify the
semantics so that, when called from an execute method,
Project.setProperty() either throws an exception (constant properties) or
works as a <property/> tag would.

later,

\x/ill          :-}


Mime
View raw message