cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoliver <>
Subject RE: POI Serialization code committed
Date Thu, 07 Mar 2002 14:54:41 GMT
> 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

> 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
( 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

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?


To unsubscribe, e-mail:
For additional commands, email:

View raw message