ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: pluggable ProjectHelper
Date Fri, 22 Feb 2002 08:23:12 GMT
From: <costinm@covalent.net>

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

As I said, I have not looked at your changes.

My only point is that if a very large amount of the ProjectHelper
file is being moved to ProjectHelperImpl. Then maybe you should
instead live it in ProjectHelper and then move the smaller part
into a ProjectFactory. Which provides the abstracted behaviour.

Helper is such a bad name. What you are doing, if I understand correctly
is implementing a Factory pattern. Well then call it Factory.

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

Yes, by the Factory.

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

Ant.java does not do a exit() I hope :)

When I mean "exactly" I mean the code should be something like:

    EmbeddedAnt(....)
    {
        Project fakeProject p = new Project();
        p.init();
        Ant a = p.createTask("ant");
        a.setTarget(targets);
        a.setParam(....);
        ...
        a.execute();
    }

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

Jose Alberto



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