ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant/proposal/myrmidon/src/manifest ant1-ant-descriptor.xml
Date Sun, 20 Jan 2002 05:28:22 GMT
On Sun, 20 Jan 2002 12:10, Adam Murdoch wrote:
> Now I'm trying to get <fileset> and friends working, and it just ain't
> going to happen without a general way to get context to the data types
> ("context" here means whatever the data type needs to evaluate itself -
> Logger, TaskContext, maybe other things).

I think there is more than that ...

> As far as I can tell, there are 2 approaches we can take:
> * Immediately prior to configuring an object, check whether it is
> LogEnabled, Composable (maybe), Contextualizable, etc and set the Logger,
> Context, etc there.  This may happen in the configurer, or maybe the type
> factory.  Either way, it happens before the setX() method is called to pass
> the object to its client task/type.

I really don't like that because then the model for task programmers can get 
really complex.

> * Pass a TaskContext into the evaluate methods of the data type.  E.g.
> public interface Path {
>     String[] list( TaskContext context ) throws TaskException;
> }

Thats kinda acceptable however I would tend to narrow down the "contexT" 
information to absolute minimum required. So in this case it would be likely 
to just pass in the basedirectory or whatever.

However there is a third option which is what I prefer. All the types exposed 
via TaskModel and related are "passive". They just contain data. If they are 
self-contained behaviour chunks then they should be modeled as tasks. If they 
are behaviour of how to do things in a certain context then you can either 
* pass the context in to their "service" methods (as described above)
* or preferrably have another "active" component/service which you pass the 
"passive" data + the current context to do the work. Hmm does that make sense?

What I mean to say is that things that need pluggable behaviour could end up 
looking like the new Exec infrastructure. Where ou generate a passive bit of 
data (ExecMetaData) pass this to the Service (ExecManager) with the relevent 
context (ExecOutputHandler or streams).

> Ant 1 uses both methods:
> Method 1: Anything that extends ProjectComponent gets contextualised during
> configuration via setProject( Project ).
> Method 2: Things like FileSet.getDirectoryScanner( Project ) and
> Path.Path( Project ).
> It would be a good thing to pick one of these methods, and apply it
> consistently.  Any preference?

I would at least attempt Method 3 (the one I described before) and then fall 
back on method 2 if Method 3 was too complex or whatever.

> Personally, I prefer ease-of-use over infinite flexibility.

Which is precisely why I like method 3 because it is conceptually simple to 
program for all parties involved.



| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message