> That's really cool stuff, however I have some wonders about the source > code that's been added to the Cocoon CVS :
This comes to me as a surprise; AFAIK it was unanimously voted upon like 2 months ago. 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. > - shouldn't all the ElementProcessor stuff be better located in the POI > CVS repository ? I don't think so. XML processing is outside the scope of POI, and besides, the elementprocessor is a generic Avalon Component framework for element processing that can be used by other Serializers. > - is Cocoon the only product in which serializing XML to XLS is usefull > ? Cocoon is the only one I'm aware of, but I can't rule this out, of course. These classes were specifically written for Cocoon, they would need rework since they are hosted as a Component. They have nothing to do with any of the existing POI APIs, they merely use them. > From what I can see, all classes in > components.elementprocessor.impl.poi.* are really POI-specific and can > be understood and maintained only by people with POI knowledge. So why > aren't they managed by the POI project itself and delivered in poi.jar ? Well, they have nothing to do with the POI project at large. They were written just so Cocoon could serialize an XML tag language (we picked one for Cocoon) to XLS. We picked one that we thought was the nicest and most widely availabe. I don't think you really need any POI knowledge if you'd like to help. The POI::HSSF API is really simple and furthermore those classes are documented not only through javadoc but the Gnumeric (http://www.gnome.org/projects/gnumeric/) XML Schema that POI committer Marc Johnson donated, as well as the DTD. > The strength of Cocoon is its ability to integrate many components >(XIndice, JFor, FOP, Velocity, to mention a few). But IMO, it should >only host "glue" classes for these components and not the components >themselves. Ahh I think you're thinking the POI project has something to do with XML or templates, but it does not. It's a Java API and implementation project to read-write legacy formats, not to do *conversions*. > From a project management point of view, we have the danger for part of > the traffic on cocoon lists being related to POI, which means noise for > Cocoon and loss of information for POI, and lots of POI-related entries > in Bugzilla (user reports and patches from the POI team). Currently, traffic on the Cocoon lists related to XML Serialization of XLS. IMHO the problem you envision is identical to the ones Cocoon has with other projects it uses. > So, what do you think about moving (back ?) the ElementProcessor stuff > to the POI CVS, and keep only the Serializers in Cocoon CVS ? I consider these to be part of the serializer to be honest. It has nothing to do with anything else in POI. I really don't want to host interface classes to all the projects we provide POI functionality that have nothing to do with POI. That would be kind of messy. I mean, I'll soon be developing MIME mappings and interfaces between POI and Lucene and I really don't want those to live in POI either (even though some will be specific to using POI from Lucene). The scope of POI seeks to be really small and focused: Java ports of OLE 2 Compound Document based file formats. We have no XML classes nor do I really want any there. If you deem this unfit for Cocoon is there an XML project somewhere for Cocoon Serializer tag implementations? It seems that there is a need of making a project that converts file formats in xml. What do you think? -Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
