Nicola Ken Barozzi wrote: >From: "Sylvain Wallez" <[EMAIL PROTECTED]> > >>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). >> > >[EMAIL PROTECTED] > 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 http://www.mail-archive.com/cocoon-dev%40xml.apache.org/msg12408.html >Anyway, my impression is that there was a bit of overheating over this >issue. >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 document. 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 [jakarta|xml]-commons. >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 >contrib. > 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 >possibilities. > 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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
