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 Mon, 22 Apr 2002 00:02:09 GMT

scratch this. It is probably best to keep the Project/Task model around as 
part of the API for workspace. But maybe we could actually implement them as
tasks under the covers (though it should be all transparent).

On Sun, 21 Apr 2002 21:47, Peter Donald wrote:
> 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 proxies.
> > 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