Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 26826 invoked from network); 21 Feb 2002 23:44:32 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Feb 2002 23:44:32 -0000 Received: (qmail 24339 invoked by uid 97); 21 Feb 2002 23:44:34 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 24297 invoked by uid 97); 21 Feb 2002 23:44:33 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 24286 invoked from network); 21 Feb 2002 23:44:33 -0000 X-Authentication-Warning: dyn-62.sfo.covalent.net: costinm owned process doing -bs Date: Thu, 21 Feb 2002 15:43:41 -0800 (PST) From: X-X-Sender: To: Ant Developers List Subject: Re: pluggable ProjectHelper In-Reply-To: <00d001c1bb20$d7625d60$0100a8c0@jose> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 21 Feb 2002, Jose Alberto Fernandez wrote: > To tell you the truth I have had no chance to look at your proposed changes, > but since in my proposal I am heavily modifying ProjectHelper > I feel concerned :-o > > If I understand correctly what you are trying to achieve, I would suggest defining > a new factory class that is the one having the createProject() method and that can be > driven by whatever is controling ANT. > > In my view ProjectHelper should stay as the default implementation used by the factory > which should mean real minimal changes to ProjectHelper as such. If ProjectHelper is not modified, then how can it delegate to a different processor ? Right now the only entry point ( except static methods that are unchanged) is the configureProject(), which calls private stuff. All the private stuff ( the actual xml processing ) just moved in ProjectHelperImpl, so any change you made can be re-done there ( obviously changes in the xml helper makes me concerned because other helpers will need to duplicate it :-). > So ProjectFactory, should be the thing to work on. Creating the project is just a side-thing, the XML processing is what I want to abstract. I need a createProject() because the helper may want to plug a different implementation ( i.e. class that extends Project ). The 'right' thing would be to have configureProject() _return_ a project, instead of beeing passed one. This way it can construct it from what's inside build.xml. But for now plugging in a different xml processor and letting the plugin create the Project impl is more than enough for all use cases, creating different Project impl. based on attributes or namespace doesn't seem like a big necesity. If we would need that, it wouldn't be very hard - it can be done using a new configureProject() method, with the old method providing backward compatibility. > This looks like something I had always thought we should have done, which is > that the behaviour of calling ANT from the command line should be exactly > the execution of: > > > > > That would have save us so many inconsistencies :( Exaclty. Except that Ant.java ( or EmbededAnt.java ) will not have the System.exit() - so it can be embedded easily in any application. > Maybe you could put your changes in the sandbox so that we can look at it more precisely. The change on ProjectHelper is pretty straightforward. I'll put the new xml processor in commons-sandbox ( it'll be a general-purpose component ). For the EmbAnt.java - I'm still workin on it, I'll send it to the list and if it's a problem I'll move it to commons-sandbox too ( as a component that embeds ant ). Costin -- To unsubscribe, e-mail: For additional commands, e-mail: