Ken, or was it Nicola wrote: ;-) (me just pretending to be the open source antropologist looking into this from the sideline)
(asbesto suit activated - fire at will) > 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? > > Possible outcomes: > 1. POI makes a sub-project with file conversion goal. > Problem: they rejected > it once, and Jakarta is not about xml. I doubt whether this 'Jakarta is not about XML' attitude is future-proof thinking, since XML is all over the place. Most, if not all Jakarta projects are using XML somewhere. :-| > 2. xml-contrib or xml-commons accepts the code. Problem: who > maintains it? > Is it in project scope? > 3. Nicola Ken makes a project on Sourceforge and puts it > there. I'm kinda > getting used to this ;-P And good at that! Unfortunately, Sourceforge might not stay the safe heaven it currently is: http://slashdot.org/article.pl?sid=02/02/13/188234&mode=thread > 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. I tend to go with the rationale that the minimal unit of packaging/containment for re-using an external project must be a properly versioned jar file. Helper classes providing bridge functionality should go inside a separate jar if necessary (poi-xml-apis.jar?). On a side remark, the S&N contribution should be treated in the same perspective, as are perhaps other major contributions (ScheCoon and the SOAP stuff come to mind). Or we should decide these to become native to the Cocoon project. Cocoon CVS is slowly becoming a mess (sorry for the harsh wording) with regards to the amount of 'cool new demos' which are dispersed across the repository. Nicola's suggestion as to isolate these into a separate contrib module seems meaningful to me. Also, the amount of documentation often varies wildly, sometimes depending on the functionality being 'native' (and looked after by a lot of people) or not (which means it was up to the original author of the contributed code to include an xdoc when sending in). So I am all unofficial +1 for having a separate module for Cocoon contributions, where we can add the POI integration work, if enough people step up as a maintainer. </Steven> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
