On Fri, 8 Mar 2002, Sylvain Wallez wrote: > giacomo wrote: > > >As always when Sylvain gets engadged he has very good arguments which > >convinced me to support moving thoes classes out of Cocoon and only > >leave the serializer and Avalon component glue code in Cocoon's CVS. > > > Thanks, Giacomo. I value your judgment as you are one of the Cocoon > "wise men".
Boy, that sound like I'm an old man :) > >We have to see where the other code will best fit into other project (if > >the POI team cannot be convinced to hold it in their CVS). > > > We should do our best to convince them that XML support in POI is a good > thing for the project (I've given a lot of reasons for that). Yup. > One of their objectives seems to keep the library as small as possible. > To achieve this, they could package the XML stuff in a separate jar > (poi-xml.jar) so that people can use only poi.jar if they don't care > about XML. Seems a valuable way to go for them. Any comments from the POI side? Giacomo > > >Giacomo > > > >On Thu, 7 Mar 2002, Sylvain Wallez wrote: > > > >>acoliver wrote: > >> > <snip/> > > >>>The package names were cross referenced with the location in the previous > >>>CVS. The only thing that has changed was the Avalonization of the > >>>serializers which Stefano and others proposed. > >>> > >>I checked the Avalonization : one implementation of Component and 4 > >>classes using getLogger(). > >> > Having thought deeper about the componentization of the serialization > stuff, I think that it doesn't really need to be a Component : > HSSFElementProcessorFactory doesn't use any of Avalon lifecycle > interfaces, and the only class using it is HSSFSerializer, which, as its > name implies, is obviously tied to this particular implementation of the > ElementProcessorFactory interface. > > As all serializers, HSSFSerializer *is* a component and declared as such > in the sitemap. But just as we don't have a "FOPProcessor" component > used solely by the FOPSerializer, we don't need a new component used > solely by HSSFSerializer. > > Not every class needs to be a component, and adding too many entries in > cocoon.xconf will be confusing for users. So what about the > "de-Avalonization" of the ElementProcessor (which means remove a useless > Component implementation and an entry in cocoon.xconf) ? Or did I miss > something that really requires it to be a component ? > > <snip what="long discussion"/> > > Sylvain > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
