cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject RE: POI Serialization code committed
Date Mon, 11 Mar 2002 20:28:17 GMT
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:

> 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

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.


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

View raw message