I would like to add my voice to this discussion. I would like to see some
kind of flow control tags in the core tasks. I think this is a hole in the
current ant tasks. Using the depends/unless target attributes is mostly
equivalent to if/then, but they are not as obvious. For new ant users, it
adds to the learning curve. And when reading through the xml file, it is
not exactly clear what is going on. Espcially with many targets defined in
the file. A simple set of <if> <then> <else> tags and maybe even a <switch>
tag would be much easier to follow and decipher. Like Larry, the first
thing I looked for was an <if> tag. It took me some time to figure out the
subtleties of the depends/unless stuff, and honestly, I am still a little
leary of it.
This is my opinion (from a relatively new user of ant), but I would bet that
many of the ant-users would probably agree. I would like it if the ant
committers at least consider it for the next version of Ant.
Thanks,
-Mark
-----Original Message-----
From: Larry V. Streepy, Jr. [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 8:56 AM
To: [EMAIL PROTECTED]
Subject: Re: for-each (another proposal)
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
method:
<target name="isAvailable">
<available file="config.xml"
property="config.xml.available"/>
</target>
<target name="copy" depends="isAvailable"
unless="config.xml.available">
<copy file="config_template.xml" tofile="config.xml"/>
</target>
<target name="deploy" depends="copy">
<!-- Do your deploy stuff here -->
</target>
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
complexity.
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
condescension.
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) mailto:[EMAIL PROTECTED]
970/626-4425 (fax) http://www.healthlanguage.com
