ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] Project/Target as Tasks
Date Sun, 21 Apr 2002 11:47:40 GMT
On Sun, 21 Apr 2002 17:28, Adam Murdoch wrote:
> 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.

What innards in particular. I had planned to specify the initial target using 
a property ala ""

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

In this case I intended the Project to put a special service in the 
ExecutionFrame so that the antcall task and depends/target tasks could all 
use this service (and thus never have to know about projects as such).

> Which suggests a marker interface, something like:
> interface CompoundTask
> {
>     void executeSubTask( String taskName ) throws TaskException;
> }

The problem with this is that implies that we get to see the physical 
representations of the task which we currently don't. Only the Executor ever 
sees the physical task objects, the rest of the system sees the ModelElement 

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

I don't think tasks should be re-entrant and with a special service exposed by 
ProjectTask I don't think it will be needed.


Peter Donald

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

View raw message