Do we have sufficient code &/ reason for a separate Cocoon-contrib cvs?
J. > -----Original Message----- > From: giacomo [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 07 March 2002 10:06 pm > To: [EMAIL PROTECTED] > Subject: Re: POI Serialization code committed > > > > 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. > > 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). > > Giacomo > > On Thu, 7 Mar 2002, Sylvain Wallez wrote: > > > acoliver wrote: > > > > >>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. > > > > > What was voted in january was (taken back from the archives) "Would you > > like the cocoon-specific POI code to be hosted in the Cocoon CVS and > > shipped with the next distribution (along with the POI library in the > > /lib directory)?". > > > > My answer to this question is +1. The goals of POI are great and having > > POI integrated with Cocoon is a must have. The problem comes from what > > we respectively understand by "cocoon-specific POI code". For all other > > components that Cocoon integrates with, this means a few glue classes. > > For POI, there are about 100 classes modelling the contents of a > > spreadsheet ! What the hell does this have to do with Cocoon ? > > > > >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(). > > > > >>- 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. > > > > > I was talking about what's in elementprocessor.impl.poi.* : I agree > > about the ElementProcessor framework. This is a generic thing that could > > well go into xml-commons or jakarta-commons for a wider use. > > > > >>- 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. > > > > > Are you really serious ???? I can't agree with that : many people use > > XML without Cocoon (even if we may consider it a bad choice ;). And how > > many projects are there in Apache that deal with XML and could benefit > > of a POI serializer ? > > > > > > > >These classes were specifically written for Cocoon, they would > need rework > > >since they are hosted as a Component. > > > > > I checked the "Avalonization" : one implementation of Component, and 4 > > classes using getLogger(). C'mon, let's get serious ! For serialization, > > the only interface that's really needed by Cocoon is > > org.xml.sax.ContentHandler. Is it Cocoon or Avalon specific ? > > > > > > > >They have nothing to do with any of the existing POI APIs, > they merely use them. > > > > > ... and Cocoon doesn't have anything to do with a spreadsheet class > > model, as it deals with XML and XML-aware components. Honestly, these > > classes are more POI's concern than Cocoon's one. > > > > >>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. > > > > > Well, you're saying here that XML is a concern of the POI team ;) > > > > Don't you think XML import/export could be a real added value to the POI > > project ? Hiding this feature in Cocoon goes against an increased use of > > POI. > > > > >>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*. > > > > > I'm not talking about templates at all. But yes, I think it would be > > good for POI to allow conversion between XML and legacy format. > > > > >>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. > > > > > I disagree. When posts are related to projects integrated with Cocoon, > > either the answer is simple and given as a reply, either people are > > directed to the respective mailing lists of these projects. With the > > serialization stuff, I envision many questions like "Andy, are you > > listening ?" (and will you be listening, since POI doesn't care about > > XML ?) or "Ask to poi-dev, they will send us a patch". > > > > >>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). > > > > > Damn ! So the aim of POI is to flood in ("pollute" came to my mind) all > > projects that want to integrate it, even if this integration relies on > > well-established standards like SAX and MIME ? Sorry, I can't be happy > > with this. There are other ways to promote POI. Having builtin XML > > support is IMHO one of these. > > > > > > > > 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. > > > > > XML is now a dominant technology in the software arena, because it moves > > software development from sequential logic to data transformation. And > > reading/writing legacy formats *is* data transformation. > > > > Don't you have great ambitions for your baby ? Announcing > > XML<->Word/Excel roundtrip support in POI is likely to attract _a lot_ > > of people. A lot more than just a Java API. > > > > > > > >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. > > > > > As said above, there may be room for the ElementProcessor framework in > > [xml|jakarta]-commons. Cocoon could use it, but other projects as well. > > > > > > > >What do you think? > > > > > You've read it inline ;) > > > > > > > >-Andy > > > > > Sylvain > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
