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? This class was not marked as deprecated. Nicola Ken had already cleverly moved the deprecated Resolver.java into src/deprecated/ I note that 'build docs' is now busted because it is not using the entity resolver anymore. This is demonstrated with the document xdocs/catalog-test.xdoc during 'build docs' and via installing/tests.html with the webapp. And if we did not have the belt-and-braces thing of copying all of the DTDs under xdocs, as well as the originals in WEB-INF, then documentation would all be broken. Why is the entity resolver now busted? I do not know, but ... The ResolverImpl.java in Cocoon uses the new version of resolver.jar from xml-commons and configures it appropriately. Is that jar compatible with the new DefaultResolver.java ? We have also lost the ability to configure the entity resolver via cocoon.xconf which was one purpose of the ResolverImpl.java I would prefer that these changes were rolled back until we talk about it. --David
