ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Did somebody say Shut up and Write? :)
Date Fri, 29 Dec 2000 12:56:38 GMT
At 05:40  26/12/00 -0600, mpfoemme@ThoughtWorks.com wrote:
>I realize that a lot of people use the ant task to run the same script with
>different sets of properties, however. This is basically a poor man's
>"template" or "macro" and is not a reason to keep the ant task around - it
>just means that we need to come up with a real macro system. The expansion
>of these macros should be done at parse time so that by the time the build
>phase begins, all of the dependencies can be sorted out. Here are some
>examples that I think need to be addressed:

My initiall reaction to this was 
Noooooooooooooooooooooooooo!!!!

then I though - oh kewl - that would unify everything ... then I remembered
that this will recause some of the problems we had with
parse-time/interpret time again. So I am back in the no camp ;) Consider
the case where directories are generated by one task and then are meant to
picked up by templates. If the templates were resolved at parse time then
this would not occur while if it occured at interpret time the tasks would
be picked up ... I prefer second approach mainly because thats what most
people seem to want and it is most consistent with rest of ant.

>I also have a question about the ability for tasks to access the ant object
>model. One thing that JDD mentions in his doc is that "the entire build
>tree is represented in memory and available to all tasks that run". Is this
>really such a good idea? How many tasks actually take advantage of this?

I think he means the tree of proxies are all in memory but the actual tasks
are created at runtime.

>I'd prefer to see a much tighter contract between tasks and their invokers.
>The biggest thing ant has going for it is the sheer number of tasks that
>have been defined for it. This api should be as small as possible, so that
>it's easy to use those tasks in a variety of settings, and to future-proof
>those tasks. I'm thinking of something EJB-ish like:

agreed.

>public interface Task {
>     public void setTaskContext(TaskContext ctx);
>     public void execute() throws BuildException;
>}

have a look at Myrmidon as that is very very close to what it defines ..
(actually it uses contextualize(ctx); instead of setTaskContext(ctx); as it
is based on Avalon and thats how Avalon does it). Instead of execute it
uses standard RUnnable interface ..

>public interface TaskContext {
>     public void info(String msg);
>     public void warn(String msg);
>     public void error(String msg);
>
>     public String getName();
>     ...
>}

Myrmidon used to have this structure but it seperated out logging to
another object that it is handed via setLogger( myLogger ); but other than
that it is similar.

>Once 2.0 ships, adding methods to the TaskContext interface should be very
>difficult and removing a method or changing a signature should be near
>impossible. By limiting which methods a task has access to, we can make
>sure that the tasks won't need to be rewritten with every release.

exactly the aim of mymidon.

>Providing access to the entire object model seems like trouble.

agreed. I think that only proxies can be manipulated except in frantic
proposal and I believe proxies will be the way to go..


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


Mime
View raw message