ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: pluggable ProjectHelper
Date Thu, 21 Feb 2002 23:43:41 GMT
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 <antlib> 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 <project> 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:
>     <ant target="targets" >
>         <param .../>
>     </ant>
> 
> 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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message