ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] Project/Module/Workspace etc
Date Thu, 06 Jun 2002 07:34:10 GMT
On Thu, 6 Jun 2002 16:06, Peter Donald wrote:
> Hi,
> Adam I noticed that you reverted a bunch of changes I was making
> Project/Module/Workspace etc and I am just curious about your motivation
> because it buggered up a bunch of my apps ;)

Oops, sorry.  Have you read WARNING.txt? =)

I was just tidying stuff up, trying to rid of those rather ugly setFrame() and 
setWorkspace() methods.  There were a lot of changes mixed in there, but only 
the project refs thing was actually reverting one of your changes.

> I had intended that that Workspace be the interface from perspective of
> tasks and thus they could just go
> myWorkspace.executeTarget( "file:/some/file.xml", "main" );

Ok, that's fine.  I think we're using the term 'workspace' for 2 different 
things.  We need both:

- A simple interface that tasks can use to execute targets.  We can call that 
a Workspace if you like.

- An interface that encapsulates the execution state of a project, so that the 
project model and execution state are separated (such that the model is 
immutable and reusable, and the state is not).  This is what I changed 
Workspace into.  I also generalised it, so that it represents the execution 
state of a module.

> But now they have to muck about with all sorts of internal brittle objects
> (aka Project/Target objects). Worse these objects are no longer immutable
> so when you are dealing with frontends such as a GUI and you want to be
> able to re-run the project you are forced to reload the main project file
> again for no good reason. You also  reverted the ProjectRef which was in
> place for much the same reason ;(

Project and Target *are* still immutable, as far as thier clients are 
concerned.  DefaultProject isn't, that's only because of a couple of assembly 
methods (and not necessarily a bad thing).  All the execution state is in 
Workspace, so a GUI could definitely re-run a project using the same Project 
object, and different workspaces.

ProjectRef I reverted, because I didn't see any real need to expose them, 
whereas exposing them means that the referenced projects *have* to be 
accessable by URL and buildable as a top level project by the embeddor.

How about some more details on what you were planning?


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

View raw message