ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry V. Streepy, Jr." <>
Subject Re: for-each (another proposal)
Date Tue, 03 Jul 2001 15:55:50 GMT
Pete, once again you've amazed me by dropping into sarcastic tones and
some false sense of superiority when responding to a reasonable email.

It is the first time I've seen "boo hoo" used as an argument against
something :-(

I'm still trying to fathom why you consider flow control "too complex"
for the ant core.  Today's content on the ant-user email list provides a
perfect example.  A user asks how I perform an if/then operation. 
Something you would think would be simple to do.  Here's the proposed

<target name="isAvailable">
  <available file="config.xml"

<target name="copy" depends="isAvailable"
  <copy file="config_template.xml" tofile="config.xml"/>

<target name="deploy" depends="copy">
  <!-- Do your deploy stuff here -->

How is this simple?  Further, this only works because the condition was
something testable with the available task.

I've seen add-on postings that provide if/then/else, switch, and loop
control for ant that are all easy to understand and use.  IMO, anyone
that is responsible for setting up a build system HAS to understand some
level of programming and simple flow control is readily understandable.

It took me several hours of reading and scanning existing build.xml
files to figure out the conditional idioms supported by ant.  My first
approach was to look for an "if" task.

You want to make ant easier to understand and faster to learn?  Put in
reasonable flow control tasks and you will accomplish that.

Further, simply because a feature is in the core does not instantly make
the core harder to use.  If I don't want to use loops, then I just don't
go read about it.  That really isn't too hard.  Take a look at what's in
the core now.  I have no need to do any SQL operations in my build, yet
the fact that there is an SQL task in the core didn't make it harder for
me to learn ant.  I spent lees time ignoring SQL than I did trying to
figure out how to do conditional operations because of ants current

Yup, I happen to think that convolution == complexity. You've refused to
include simple constructs (which all programmers are familiar with) and
have built in several different ways of accomplishing the same thing. 
Targets have an if/unless attribute, but tasks do not. Some tasks, like
patternset, allow an if/unless, but others, like property, do not.  Now
I have to learn all the different ways in which conditionals have been
implemented in order to use ant.  THAT IS MORE COMPLEX.

And I disagree that telling us to go learn another language/system is a
reasonable solution to iteration.  Basic iteration, which will probably
cover 90% of the needs I've seen discussed on this list, is trivial to
implement directly within ant.

Now, hopefully, I'll get some other response than sarcasm or

In fact, I'd like to hear from the other commiters, or is Pete speaking
for the group on this issue?

Peter Donald wrote:
> On Tue,  3 Jul 2001 18:39, Peter Vogel wrote:
> > It's interesting that you say this.  Because the same is true for
> > me, and has been for the 12 or so years I've been implementing
> > builds for one thing or another -- developers (whether C, C++,
> > Java or otherwise) generally consider build automation "beneath"
> > them (though they could not live without it) and so do not want to
> > be bothered with the intricacies of *any* build tool, whether it
> > be make, Ant, or (God forbid) shell scripts.  Therefore, to me the
> > *key* requirement for a build tool is that it supports the construction
> > of an "infrastructure" which defines a project/company specific
> > environment of *conceptually simple* constructs that are reusable from
> > project to project within the company and where a project build file is
> > a "no brainer" for the developers -- the intelligence is embedded in the
> > infrastructure, where it can be explained to the small cadre of people who
> > care or have interest in such things, and where it can be appropriately
> > grown to meet the evolving needs of the company.
> Similar arguements are made for things like TCL or lisp. Given a few basic
> operations (5-6 in those cases) all the rest of infrastructure comes for free
> (or via add in modules).
> Neither really took off commercially (well except for maybe tcl but some
> would argue that is because of tk) not because they weren't good. But because
> to use it effectively required substantial knowledge and understanding.
> Things that people weren't willing to invest in to PLs. Do you think they are
> even more likely to invest it in a build infrastructure? (Before you answer
> that look at how most non-build engineers deal with Make).
> > So, here's my problem with all your "template" concepts: they require that
> > I (and, more importantly, others who will inherit the infrastructure that
> > I construct, whether it be 6 weeks or 6 years from now) study and
> > understand yet another tool/language/etc. to do what can be done neatly and
> > cleanly within
> > the core of ant in a far simpler manner conceptually.
> So let me see if I have got this correct. Build engineers want to do complex
> things. Hence you want complexity imported into ant "language" making it
> possible to do what you want. Because in your situation you have some one
> that can be dedicated to maintiang build process. It doesn't matter to you
> that other projects that don't need a build engineer will be paying for
> complexity because you will never be in that situation.
> And this is all to avoid learning a templating language. Even though that
> language is potentially a standard language whos basics could be understood
> in .... what about 40 minutes? Well all I can say is ... boo hoo.
> Cheers,
> Pete
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*

Larry V. Streepy, Jr.
Chief Technical Officer and VP of Engineering

Health Language, Inc.  -- "We speak the language of healthcare"

970/626-5028 (office) 
970/626-4425 (fax)    

View raw message