ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] Project/Target as Tasks
Date Sun, 21 Apr 2002 07:28:01 GMT
On Sun, 21 Apr 2002 13:53, Peter Donald wrote:

> Currently I have to rework a lot of infrastructure in myrmidon to get it to
> fly (ie new embeddor, new builders, new workspace-like object, new model).
> However if we were to go go to a generic infrastructure where
> project/target etc were just tasks, workspace just contains instance data
> and ProjectBuilder were genericised then I would not have to do anything
> more than write a few tasks and set a few properties and that would be all
> good ;)

Things aren't quite as grim as you make out.  All you need is a project 
builder that spits out a project with a single target, containing just the 
mega-task.  Then you can reuse the embeddor, model and workspace (and all the 
other good stuff like the listeners and the frontends).  Doesn't sound like 
that much more work than the generalised case.

Having said that, I still think it's a fine idea to pare down the project 
model.  The question is where do we stop chopping?  We don't want to end up 
with an opaque project object with a single 'do something' method on it.  We 
want to allow controlled exposure of the innards of the executable thing 
(project, target, task container, whatever), so that we can reference the 
innards from elsewhere (the command-line, depends="", <antcall>, 
<project-ref>, etc), and so that we can write infrastructure.

> > Perhaps if we were to explicitly model container tasks, that would work
> > for projects and targets as well.
> Im not sure I understand - wanna enlighten me ? :)

Yeah, I'm not sure I understand that either :)

What I meant: Often we don't want to execute an entire project - we want to 
execute a target.  And there's a whole host of places where we want to be 
able to do this from: the command-line, <antcall>, in a target's 
dependencies, programmatically, etc.  Some of these cases would be handled in 
the project's execute() method, but others cannot.  Dependencies, for 
example, would be handled by the project.

If we do reduce the project model to a single Task object, we still want some 
way to get at the targets of the project, so that we can execute them.  And 
we want to be able to do this without caring what type of project it is.

So, I think we want to generalise the target concept a little.  That is, model 
the project as a compound task, which is a task with a set of named 
sub-tasks.  The sub-tasks can be execute individually by name, or as a whole.  
Of course, for some project types, the named sub-task thing won't make any 
sense (e.g. the cron server).

Which suggests a marker interface, something like:

interface CompoundTask 
    void executeSubTask( String taskName ) throws TaskException;

The project builders would return an object that implements Task.  If that 
object happens to implement CompoundTask, then that is used to get at the 
sub-tasks.  If that object doesn't implement CompoundTask, then it can only 
be executed as a whole.  This approach could be used recursively, so that you 
could reference tasks at any depth.

Modelling a project as a task does raise some reentrancy issues.  Projects 
(or, at least, parts of them) can be executed recursively and/or 
concurrently, but that is definitely not part of the contract of the Task 
interface atm.  And I don't think we want to add it, since it would force 
every task implementation to worry about concurrency, when there's abolutely 
no need, except for the handful of project tasks.


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

View raw message