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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
