ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject AntBean feedback
Date Thu, 28 Feb 2002 09:49:01 GMT
There seems to be bucketloads of things being thrown around at the 
moment and it is honestly difficult to do them all justice at the same 
time. I think we are going to need a fair amount of time to properly 
review and consider all the proposals.

Anyway, let me make a start with Costin's AntBean proposal. I'm going to 
focus on the refactoring of Main into Main + AntBean. The other stuff in 
that sandbox to do with task adapters, task factories, refactored 
ProjectHelper, etc, I have not gone into.

I support the AntBean concept. We have said in the past that Main is not 
right integration point for putting Ant into another system. The rule 
has been that you should choose to embed Project. The truth is that 
there is some functionality that has been provided in Main that really 
you need to use (firing project start events, for example) when 
embedding. People who have done the right thing have not much choice but 
to reimplement code from Main which is bad. OTOH, embedding Main is also 
bad.

I think Costin's proposal has a few problems which are the same reasons 
that Main should not be embedded in its current form. I also have a few 
questions. In the following, when I refer to "container" I am talking 
about the object which is embeddeding the AntBean instance,

1. Why is AntBean a task? I don't really see the benefit. It just seems 
to be a complication.

2. The AntBean should not touch System.out, System.err nor setup a 
SecurityManager. These are the responsibility of the container to setup. 
I wouldn't want a bean to be mucking around with System.out.

3. Similarly a bean should have no concept of a logger. In Main, a 
logger is the listener which has the reponsibility to write to to 
System.out. That is a concept of the container, not the bean.

4. The bean should not be creating listeners or loggers. Again, this is 
the responsibility of the container. If the container is a GUI, for 
example, the Ant core may not be capable of instantiating the listener. 
The bean should just have addListener, removeListener methods.

5. getProject is badly named. In general get methods should not have so 
many side effects. This should be split into an init method

6. Output level is not required. The container's listeners and logger 
decide what to do with logged messages.

7. The find build file should probably be removed. I think it is the 
container's responsibility to find the build file and give it to the bean.

8. You probably want to change the implementation of this method
     public void setCoreLoader( ClassLoader coreLoader ) {
         coreLoader=coreLoader;
     }

9. The done method should probably be final to prevent subclasses from 
forgetting to fire the build finished event. You may want to add another 
template method to allow subclasses to cleanup.

10. pushSystemOut and popSystemOut methods are badly named since they 
suggest you can call them more than once, which you can't, since you'll 
destroy the values of oldErr and oldOut. Besides they do much more than 
munge System.out.


Cheers
Conor


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