cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: POI Serialization code committed
Date Mon, 11 Mar 2002 15:30:29 GMT
Nicola Ken Barozzi wrote:

>From: "Sylvain Wallez" <>
>>giacomo wrote:
>>>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).
Subscribed !

>>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.
>File format conversion is not a POI objective.
>It's cool, I love the idea, I even proposed it when the project was still on
>sourceforge, but it got rejected.
For people on poi-dev who don't know what this is all about (BTW 
congrats for your nomination as a POI committer, Ken), let's summarize 
by saying that I was very surprised by seeing more than 100 classes 
added in Cocoon's CVS for the HSSF serializer. The Cocoon team voted +1 
in January for accepting Cocoon-specific code for POI integration, but 
integration of third-party tools in Cocoon is most often a matter of a 
few classes, and not 100 classes modelling a spreadsheet.

For full in-depth info on this, see

>Anyway, my impression is that there was a bit of overheating over this
>Anyone can have opinions, but please let's stick to practical solutions and
>(possibly) patches instead of whining (not directed to anyone in particular
>and at the same time to all, me too).
>So, now for some facts:
>1. POI doesn't have file conversion as its scope. Niether that of converting
>to-from XML. Communities can always change opinions, revolutionaries can
>have their way, but for now this is where POI stands.
I strongly suggest the POI project to reconsider this decision. XML 
support would attract a lot of users, much more than a Java API. And 
Cocoon isn't the only XML framework out there.

>2. Some Cocoon committers are nervous of having so much non-core Cocoon code
>in CVS, for many different but mostly sensible reasons. The Serializers are
>ok, but the elementprocessor component is not something they agree on.
So much classes modelling a spreadsheet can hardly be thought to be in 
the scope of Cocoon.

>3. I committed the code, so I feel I should get this sorted out. I stand in
>between, and understand both POV. For what I see, if both have it their way,
>Cocoon looses POI functionality and POI looses XML functionality.
The main point is the limit between Cocoon and POI. A standard 
third-party interface perfectly defines this limit : 
org.xml.sax.ContentHandler, which defines the event handlers for an XML 

Nothing more is needed to built a serializer. It doesn't make POI 
dependent on Cocoon, and integration of a specific ContentHandler in 
Cocoon is a breeze (a single class). The same applies to generators.

>The only logical solution I see now (correct or enhance this point at will),
>is that the elementprocessor code seems to belong to a *third* project. A
>project that makes binary<->XML file format conversion. The problem is:
>where is it? Community? Who maintains it?
I guess you're talking about the generic framework, not the 
HSSF-specific implementation. As said previously, this could go to 

>Possible outcomes:
>1. POI makes a sub-project with file conversion goal. Problem: they rejected
>it once, and Jakarta is not about xml.
IIRC, there was a long time ago a discussion about moving Cocoon to 
jakarta : the main focus of Apache XML is the implementation of standard 
specifications related to XML. Cocoon is there for historical reasons, 
but better fits in Jakarta's goals, in the "Frameworks and Engines" or 
"Server Applications" sections.

>2. xml-contrib or xml-commons accepts the code. Problem: who maintains it?
>Is it in project scope?
The element processor framework is in the commons project scope 
(although xml is more restrictive than jakarta). Not the full HSSF 
serializer. Since every committer is also a committer on commons, 
maintaining it shouldn't be a problem.

>3. Nicola Ken makes a project on Sourceforge and puts it there. I'm kinda
>getting used to this ;-P
That would be IMO the worst solution :(

>4. Cocoon makes a xml-cocoon-contrib or xml-cocoon-extra module where extra
>components are put. IMHO it could accomodate all other optional Cocoon
>stuff, like XML-DB for example, and finally make Cocoon distro a bit leaner.
>The main distro can keep only basic samples, and all extra samples go in
Cocoon already has many third-party jars, and cannot hold all 
implementations of ContentHandler in the world. Even more if these 
implementations are related to another Apache project.

>So, what do you guys prefer?
>I'm cool with all of them, and ready to hear of other practical
5. POI hosts the HSSF element processor in its contrib directory, and 
Cocoon hosts the serializer glue class and samples, just as for other 
tools integration. In order to keep poi.jar small and clean, the 
serializer can be packaged in a separate poi-xml.jar, and Cocoon adds 
this new jar to poi.jar in its optional lib directory.

Thoughts ?


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message