cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Finishing Deprecation Package
Date Thu, 13 Mar 2003 13:21:35 GMT
David Crossley wrote:
> 
> On Tue, 2003-03-11 Carsten Ziegeler wrote:
> > As I will not do it this week, here is a list of
> > things that have to be done to get the deprecation
> > package working. If someone wants to do it, I will
> > be very happy - otherwise I will perhaps do it
> > next week.
> > 
> > The XScriptObject must be changed to inherit from the
> > excalibur source instead of the cocoon source. It might
> > be, that a logicsheet needs to be adapted as well.
> > 
> > The Source interface from Cocoon and the 
> > CocoonToAvalonSource class have to be moved from the
> > deprecated package into the core package.
> > 
> > org.apache.cocoon.components.resolver.ResolverImpl has
> > to be changed to use the new Resolver from the excalibur
> > xmlutil package.
> 
> Whoa, not so fast Carsten. I see that you have suddenly
> ripped out the comprehensive ResolverImpl.java and
> replaced it with a basic DefaultResolver.java ... Why?
> What is the reason for these drastic changes and why
> was there no discussion?
> 
It's not a drastic change. 

> This class was not marked as deprecated. Nicola Ken had
> already cleverly moved the deprecated Resolver.java into
> src/deprecated/

Yes, but ResolverImpl depends on Resolver, so you have a
dependency from the core to the deprecated package and
this has to be avoided.

> We have also lost the ability to configure the entity
> resolver via cocoon.xconf which was one purpose of
> the ResolverImpl.java
> 
This is not true (unless it's a bug). In fact, if you compare
the code, the new DefaultResolver is absolutely the same as
the old ResolverImpl, so it should still be configurable and
working as the old one.

If anything is not working the way it should, it's simply a
bug which has to be fixed.

Carsten

Mime
View raw message