Peter,
A couple of notes. I definitely appreciate your (and the rest of the ant-dev)
teams efforts. Ant is taking over as our installer. Right now it's all based
on running on the command line with a properties file. Some of it involves
subprojects,
which prompt the user when required properties are not found. Eventually,
it will probably have a gui front end on it, which will edit the properties,
and kick off ant.
I understand that your vision of ant does not involve making it a scripting
language.
However, like myself, most users need some basic constructs for flow control.
I think the ContainerTask will definately be a step in that direction allowing
users to develop their own tasks. But, in a lot of cases, the people
developing the ant input files are not necessarily java programmers,
and could not really code up their own tasks, or effectively make their
own conditionals. I myself am willing to do that, but most users are not
either willing or capable of doing this. I just happen to work for a small
company,
and don't have the luxury of having someone else build my install scripts for
me.
I'm not saying you have to provide a complete flow control solution, but at
lease some basic constructs such as "if/elseif/else", and "foreach". Switch
is not necessary, as it can be done with an if (and would in effect probably
be the same code anyway).
It would serve 2 purposes..
1) it would make user's lives easier
2) it would make your life easier because you'd have to stop
hearing the same request over and over again.
just my $.02
And i'm more than willing to contribute to the development effort.
Peter Donald wrote:
> This will be provided by Ant2. I think we have even voted on it. Except we
> called it ContainerTask.
>
> On Wed, 4 Jul 2001 05:37, [EMAIL PROTECTED] wrote:
> > ok, well i've been peeking at the "for-each" thread for a while, and can
> > see where it's going. The bottom line is that many users see the need for
> > some form of simple control flow structures. Shouldn't tools
> > be driven by the basic user requirements? That's my $.02 on that
> > topic. And i won't get into the debate on inclusion into the core,
> > but rather support for users to create their own conditionals.
> >
> > Onto something more useful. It would be nice to modify
> > the ant core to be able to have one task execute a series of other
> > tasks. This would allow people to create their own types of custom
> > conditionals which would work from one version of ant to another.
> > Currently, you could in create a Task subsclass like:
> > ( I already have done this, so it works )
> >
> > // ***************** BEGIN CODE
> >
> > public class TaskContainer extends Task
> > {
> > public Task createAnt() { ... };
> > public Task createAntCall() { ... };
> >
> > public void execute() throws BuildException
> > { /* execute all the created tasks underneath this one */ };
> > }
> >
> > public class MyConditional extends TaskContainer
> > {
> > public void execute() throws BuildException
> > {
> > if (condition.evaluate()) super.execute();
> > else { /* do some elseif style stuff here in the same manner */ }
> > }
> >
> > ....
> > }
> >
> > // ************************** END CODE
> >
> > but that creates trouble from one version of ant to another, as you have
> > to make create methods in the TaskContainer for every builtin and optional
> > task that ant defines. Plus the above way has the drawback of not being
> > able to put custom tasks inside these task containers. What would be an
> > elegant way to do this is to create the following class:
> >
> > // ********************* BEGIN CODE
> >
> > package org.apache.tools.ant;
> >
> > import java.util.ArrayList;
> > import java.util.Collections;
> > import java.util.Iterator;
> > import java.util.List;
> >
> > public class TaskContainer extends Task
> > {
> > protected List subtasks = new ArrayList();
> >
> > void addSubtask(Task t)
> > {
> > subtasks.add(t);
> > }
> >
> > List getSubtasks()
> > {
> > return Collections.unmodifiableList(subtasks);
> > }
> >
> > protected void executeSubtasks()
> > throws BuildException
> > {
> > Iterator it = subtasks.iterator();
> > while (it.hasNext())
> > {
> > Task t = (Task)(it.next());
> > t.execute();
> > }
> > }
> >
> > public void execute()
> > throws BuildException
> > {
> > executeSubtasks();
> > }
> > }
> > // ********************* END CODE *************
> >
> > and then in IntrospectorHelper.java:
> >
> > // ********************** BEGIN CODE
> > public Object createElement(Object element, String elementName)
> > throws BuildException {
> > NestedCreator nc = (NestedCreator) nestedCreators.get(elementName);
> >
> > if (nc == null && element instanceof TaskContainer)
> > {
> > TaskContainer task = (TaskContainer)element;
> > Project p = task.getProject();
> > Map tasks = p.getTaskDefinitions();
> > if (tasks.containsKey(elementName))
> > {
> > Task t = p.createTask(elementName);
> > task.addSubtask(t);
> > return t;
> > }
> > }
> > else if (nc == null) {
> > String msg = "Class " + element.getClass().getName() +
> > " doesn't support the nested \"" + elementName + "\"
> > element"; throw new BuildException(msg);
> > }
> > ....
> > }
> >
> > // ********************* END CODE ********************
> >
> > and then you could extend TaskContainer as in the first example,
> > and simply call super.execute() whenever you wanted to execute
> > all the tasks that were added to the container. It doesn't throw off
> > the basic design of ant, and is a relatively simple and innocuous way
> > to allow users to add their own conditionals (or support future
> > conditionals in the core, if it's decided that they are to be added at
> > a later date).
> >
> > Thoughts anyone?
> >
> > Peter Donald wrote:
> > > On Wed, 4 Jul 2001 01:06, Chris Greenlee wrote:
> > > > Peter (Donald),
> > > >
> > > > <offtopic>
> > > > Apologies, but your tone is quite often abusive. People who post
> > > > thoughtful comments ought not to be insulted just because you disagree
> > > > with them.
> > > > </offtopic>
> > >
> > > If I post the same thing 15 times does it become thoughtful the 15th
> > > time? I am not sure how long you have been on this list but he has been
> > > repeating like a drone the same things over and over and over again for a
> > > few months now. We listened the first time but now it is just noise. I
> > > thought I was relatively polite given the history.
> > >
> > > > Now, to continue this thread with some responses to your objections, as
> > > > I have seen them:
> > > >
> > > > Objection #1: Adding flow-of-control tasks makes Ant more complex for
> > > > the user.
> > > >
> > > > Response #1: Adding more tasks -- any tasks -- increases the complexity
> > > > of the tool, in a trivial sense: there are more tasks to choose from,
> > > > and so choosing the appropriate task to use requires reading more
> > > > documentation. Adding if/then, switch, foreach, etc. tasks or
> > > > constructs will, in this trivial sense, increase the complexity of the
> > > > tool. However, people are not required to use each and every task
> > > > provided with Ant. I myself use only about 14 Ant tasks -- <ant/>,
> > > > <antcall/>, <available/>, <cvs/>, <ftp/>, <foreach/>, <jar/>, <javac/>,
> > > > <javadoc/>, <junit/>, <junitreport/>, <javadoc/>, <property/>, and
> > > > <style/> -- while there are over 40 just in the core. Adding more
> > > > tasks gives the user the ability to create more complex build scripts,
> > > > but it does not require them to do so. Moreover, flow-of-control tasks
> > > > in particular, when properly used, may well simplify build scripts,
> > > > making them smaller, easier to understand, and easier to maintain.
> > >
> > > Put bluntly, the vast body of research in natural language and artificial
> > > language theory disagrees with you. If you look at the evolution of
> > > natural languages then it becomes obvious. More evolved languages have
> > > smaller sets of symbols but are able to express more meanings. Compare
> > > modern English to ancient Egyptian. English has 26 symbols while ancient
> > > Egyptian has a bunch - lets say 5000 (no idea just guessing). English can
> > > expresse more meanings despite this. The reason for it is because of all
> > > those extra word classes and rules to manipulate (aka flow control for
> > > NL). English is the more difficult language to learn despite having fewer
> > > essential symbols.
> > >
> > > Theres similar findings in artificial language theory. Why do languages
> > > like lisp with all their power not see use. It is not because they are
> > > not good but more because they require more knowledge from user.
> > >
> > > Adding flow control to ant also increases knowledge required to manage
> > > build files. This is great if you are build engineers but sucks
> > > otherwise. Not surprisingly the build engineers on the list want it to be
> > > added ;) You may claim that addition of a few tasks is not a biggie.
> > > However if you look through the archives you will see there is a large
> > > number of side effects from this decision and it will decisions in
> > > unrelated areas. It will also open path to other requested functionality.
> > >
> > > I am a believer in doing one thing well. Currently ant does too many
> > > scripty things and encourages too many bad practices. These will
> > > hopefully be eliminated in ant2 but who can tell at this stage.
> > >
> > > > Objection #2: Adding flow-of-control tasks makes Ant more complex for
> > > > the maintainers.
> > >
> > > Never been an objection per se. The objection was (1) which would lead to
> > > (2) because developers would have to support people who do stupid things
> > > but aren't educated enough to know when they are doing stupid things.
> > >
> > > > Objection #3: Ant is not a scripting language, and adding
> > > > flow-of-control tasks would make Ant a scripting language.
> > > >
> > > > Reponse #3: Most scripting languages are characterized not merely by
> > > > flow-of-control operators, but by extensive string manipulation
> > > > libraries, lack of type checking, implicit variable declarations, etc..
> > > > Adding flow-of-control tasks to Ant will not suffice to make Ant a full
> > > > fledged scripting language, or anything close.
> > >
> > > The addition of flow control would not be the end of it. If you look over
> > > the archives, us "thought police" (aka ant-dev) have been asked for the
> > > same things you mention. We already have or will have "lack of type
> > > checking, implicit variable declarations". The other thing that we are
> > > always asked for is logic operators. The only thing keeping ant from
> > > being a scripting language in ant2 will be the lack of flow control. The
> > > rest we will have (and I will be providing certain flow control tasks
> > > outside core anyways).
> > >
> > > 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 |
> > >
> > > *-----------------------------------------------------*
> >
> > --
> > Matt Inger ([EMAIL PROTECTED])
> > Sedona Corporation
> > 455 S. Gulph Road, Suite 300
> > King of Prussia, PA 19406
> > (484) 679-2213
> > "Self-respect - the secure feeling that no one,
> > as yet, is suspicious." -H.L. Mencken
>
> --
> 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 |
> *-----------------------------------------------------*
--
Matt Inger ([EMAIL PROTECTED])
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
as yet, is suspicious." -H.L. Mencken
