ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: AntBean feedback
Date Thu, 28 Feb 2002 15:56:49 GMT
Conor, 

Thanks for the review,

On Thu, 28 Feb 2002, Conor MacNeill wrote:

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

I'll remove it. I wanted to have <ant> extend AntBean, but the same 
thing can be done with delegation.


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

I partially agree. I wanted AntBean to have the same 'power' as 
Main - if Main can redirect the output to the logger, so should
the bean. However in 'normal' use the container will not call
those methods ( they are called from Main ). 

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

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

The idea was to provide the same capabilities with Main. A GUI container
can use it's own listeners/loggers, but if you want ant embedded in
a simpler program you don't want to cut&paste Main again.

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

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

I see your points. 

The question is if we want AntBean to provide the same functionality
as Main, and 'making simple things simple' - i.e. the user code
will just have to:

  AntBean antBean=new AntBean();
  // set some properties, same as Main's CLI
  antBean.execute();

This would do the same as calling Main would. 

User code could have fine-control over each step of the process -
register a different logger, add Tasks/Targets programatically,
execute individual Tasks ( even without a Target or build.xml :-),
etc.

If we don't want this 'equivalence', then it may be better to remove
AntBean and improve Project to make it easier to embed it - 
but again in this case I would move at least the creation of the
default logger in Project.

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