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]
> 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.
> >>I checked the Avalonization : one implementation of Component and 4
> >>classes using getLogger().
> >>
> Having thought deeper about the componentization of the serialization
> stuff, I think that it doesn't really need to be a Component :
> HSSFElementProcessorFactory doesn't use any of Avalon lifecycle
> interfaces, and the only class using it is HSSFSerializer, which, as its
> name implies, is obviously tied to this particular implementation of the
> ElementProcessorFactory interface.
Technically it's not necessary. But IMHO it seems reasonable that a
framework as elementprocessor can be seen as a Component. But it seems it's
like talking of what sex an angel is (Italian saying ;-)
> As all serializers, HSSFSerializer *is* a component and declared as such
> in the sitemap. But just as we don't have a "FOPProcessor" component
> used solely by the FOPSerializer, we don't need a new component used
> solely by HSSFSerializer.
Talking about impl classes? In this case, I can't really disagree.
But then, when is it clear that something is a Component?
I think this belongs to another thread, the one on Componentization and
Blocks.
> Not every class needs to be a component, and adding too many entries in
> cocoon.xconf will be confusing for users.
True. But this is not a technical reason. I could say that every class
*could* be a Component, and that cocoon.xconf can help configure things
better if more used.
We could go on forever, and get nowhere.
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.
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.
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 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.
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
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.
So, what do you guys prefer?
I'm cool with all of them, and ready to hear of other practical
possibilities.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
