You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by acoliver <ac...@nc.rr.com> on 2002/03/07 15:54:41 UTC
RE: POI Serialization code committed
> 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.
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.
> - 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.
> - 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.
These classes were specifically written for Cocoon, they would need rework
since they are hosted as a Component.
They have nothing to do with any of the existing POI APIs, they merely use
them.
> 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.
> 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*.
> 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.
> 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).
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.
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.
What do you think?
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XSLTrace revived
Posted by Steven Noels <st...@outerthought.org>.
Ivelin,
>From the license agreement that comes with the IBM version:
[...]
1. Ownership and License.
The Software is owned by International Business Machines Corporation or
one of its subsidiaries ("IBM") and is copyrighted and licensed, not
sold.
IBM grants you a non-exclusive, non-transferable license to download the
Software and use it only for your personal, non-commercial and lawful
end use. Implied licenses are negated.
You may copy the Software for backup only. You may not: 1) merge,
distribute (for free or for sale) or sublicense the Software; 2) reverse
assemble, reverse compile, or otherwise translate the Software.
[...]
Furthermore, I'm quite sure that only the license owner is able to
change the license of a product. And unlawfully changing the license of
a product to an ASL-type license is not the kind of press ASF is
seeking...
Sorry,
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLTrace revived
Posted by Ivelin Ivanov <iv...@iname.com>.
Folks,
I've just uploaded to my sourceforge account a revived version of XSLTrace
which IBM released 3 years ago but then stopped supporting.
The new version doesn't have new functionality, but it works with JDK 1.4
and Xalan 2.3.1
I was wondering if there would be any interest in it as a tool for Cocoon.
Should I suggest it to Xalan for the set of Xalan samples.
Or should I just stop bother people with irrelevant questions ?
It's @
http://prdownloads.sourceforge.net/freebuilder/XMLScratchPad_05.zip
If there is someone that thinks IBM won't be happy about this tool going
under the Apache License, it's relatively trivial to rewrite from scratch.
But I figured since IBM were so good to donate so much to the Apache XML
community already, they wouldn't mind one of their original works which they
don't have time to support themselves to benefit the Apache group.
Regards,
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>>
>> 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 ?
>
Gosh. This badly reminds me of
http://marc.theaimsgroup.com/?t=101073878600001&r=1&w=2
Now I start to understand what was CVS access about. And my worst
nightmares are slowly reemerging...
Is there anything we|Ken|POI team can do to have a generic XML interface
to POI and move it to general?
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: POI Serialization code committed
Posted by Per Kreipke <pe...@onclave.com>.
> > 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.
You bet it would be great, after all, Office 2000 and XP use native XML
formats to store their data. Sure would be nice to convert older, legacy
docs into those formats easily, via Java!
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>
>>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).
>>
>
>poi-dev@apache.org
>
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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: POI Serialization code committed
Posted by Steven Noels <st...@outerthought.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> 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).
poi-dev@apache.org
> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> 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).
poi-dev@apache.org
> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> >>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.
> >
> >Seems a valuable way to go for them.
> >
> >Any comments from the POI side?
> >
> Not up to now. And this makes me wonder even more about the support of
> these 100+ classes... I'm gonna bring this discussion to poi-dev. Gosh,
> one more mailing list :(
In a previous mail, I think I've defined possible concrete outcomes as
clearly as possible.
There has been no response to those points, only a suggestion of what
another project community should do for his good.
In case you didn't recieve the mail, I reminded that the POI community has
already decided not to have xml stuff in the repository; this requirement
was part of the proposal to jakarta, for being accepted in Apache.
Since there have been two votes done by these communities, all on donating
the code to Cocoon, the code has been put in the Cocoon repository, but by
no means this is written in stone. Communities can change their mind, as it
seems it's happening now, and this is a good thing as long as it doesn't
create unnecessary friction.
Now that the whole issue has come to a stall, we, the POI development team,
are deciding on how to deal with this without creating further problems for
our communities.
We will make our position clear in a mail that will be posted ASAP.
We are confident that the solution we are working on will please all.
Thank you for the patience.
Nicola Ken
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by gi...@apache.org.
Quoting Sylvain Wallez <sy...@anyware-tech.com>:
> giacomo wrote:
>
> >On Mon, 11 Mar 2002, Sylvain Wallez wrote:
> >
> >>giacomo wrote:
> >>
> >>>On Fri, 8 Mar 2002, Sylvain Wallez wrote:
> >>>
> >>>>giacomo wrote:
> >>>>
> >>>>>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.
> >>>>>
> >>>>Thanks, Giacomo. I value your judgment as you are one of the Cocoon
> >>>>"wise men".
> >>>>
> >>>Boy, that sound like I'm an old man :)
> >>>
> >>You can't say you're not a Cocoon old-timer ;)
> >>
> >No, I can't say I'm an Cocoon old-timer but a "wise men" has a long
Correction: "No, I can't say I'm *not* an Cocoon old-timer ..."
> >beard doesn't have to learn anymore and uses a cane to walk :/ I might
> >be old compared to the average age of the Cocoon comunity but I don't
> >feel *that* old.
> >
> Sorry, Giacomo. I didn't mean any offense, as I don't know your age. I'm
I'm not offended but amused :)
> 35 which is AFAIK older than most committers here. And even "wise
men"
Welcome to the club of 30+ years old "wise and semi-wise mens" like me
(42) and
some others I knew of :)
> still have to learn to increase their wisdom ;)
Ok, than I accept being a "wise men", thanks :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo wrote:
>On Mon, 11 Mar 2002, Sylvain Wallez wrote:
>
>>giacomo wrote:
>>
>>>On Fri, 8 Mar 2002, Sylvain Wallez wrote:
>>>
>>>>giacomo wrote:
>>>>
>>>>>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.
>>>>>
>>>>Thanks, Giacomo. I value your judgment as you are one of the Cocoon
>>>>"wise men".
>>>>
>>>Boy, that sound like I'm an old man :)
>>>
>>You can't say you're not a Cocoon old-timer ;)
>>
>No, I can't say I'm an Cocoon old-timer but a "wise men" has a long
>beard doesn't have to learn anymore and uses a cane to walk :/ I might
>be old compared to the average age of the Cocoon comunity but I don't
>feel *that* old.
>
Sorry, Giacomo. I didn't mean any offense, as I don't know your age. I'm
35 which is AFAIK older than most committers here. And even "wise men"
still have to learn to increase their wisdom ;)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by giacomo <gi...@apache.org>.
On Mon, 11 Mar 2002, Sylvain Wallez wrote:
> giacomo wrote:
>
> >On Fri, 8 Mar 2002, Sylvain Wallez wrote:
> >
> >>giacomo wrote:
> >>
> >>>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.
> >>>
> >>Thanks, Giacomo. I value your judgment as you are one of the Cocoon
> >>"wise men".
> >>
> >
> >Boy, that sound like I'm an old man :)
> >
> You can't say you're not a Cocoon old-timer ;)
No, I can't say I'm an Cocoon old-timer but a "wise men" has a long
beard doesn't have to learn anymore and uses a cane to walk :/ I might
be old compared to the average age of the Cocoon comunity but I don't
feel *that* old.
Giacomo
>
> >>>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).
> >>
> >
> >Yup.
> >
> >>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.
> >>
> >
> >Seems a valuable way to go for them.
> >
> >Any comments from the POI side?
> >
> Not up to now. And this makes me wonder even more about the support of
> these 100+ classes... I'm gonna bring this discussion to poi-dev. Gosh,
> one more mailing list :(
>
> Sylvain
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo wrote:
>On Fri, 8 Mar 2002, Sylvain Wallez wrote:
>
>>giacomo wrote:
>>
>>>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.
>>>
>>Thanks, Giacomo. I value your judgment as you are one of the Cocoon
>>"wise men".
>>
>
>Boy, that sound like I'm an old man :)
>
You can't say you're not a Cocoon old-timer ;)
>>>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).
>>
>
>Yup.
>
>>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.
>>
>
>Seems a valuable way to go for them.
>
>Any comments from the POI side?
>
Not up to now. And this makes me wonder even more about the support of
these 100+ classes... I'm gonna bring this discussion to poi-dev. Gosh,
one more mailing list :(
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by giacomo <gi...@apache.org>.
On Fri, 8 Mar 2002, Sylvain Wallez wrote:
> giacomo wrote:
>
> >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.
> >
> Thanks, Giacomo. I value your judgment as you are one of the Cocoon
> "wise men".
Boy, that sound like I'm an old man :)
> >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).
Yup.
> 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.
Seems a valuable way to go for them.
Any comments from the POI side?
Giacomo
>
> >Giacomo
> >
> >On Thu, 7 Mar 2002, Sylvain Wallez wrote:
> >
> >>acoliver wrote:
> >>
> <snip/>
>
> >>>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().
> >>
> 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.
>
> 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.
>
> Not every class needs to be a component, and adding too many entries in
> cocoon.xconf will be confusing for users. So what about the
> "de-Avalonization" of the ElementProcessor (which means remove a useless
> Component implementation and an entry in cocoon.xconf) ? Or did I miss
> something that really requires it to be a component ?
>
> <snip what="long discussion"/>
>
> Sylvain
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo wrote:
>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.
>
Thanks, Giacomo. I value your judgment as you are one of the Cocoon
"wise men".
>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).
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.
>Giacomo
>
>On Thu, 7 Mar 2002, Sylvain Wallez wrote:
>
>>acoliver wrote:
>>
<snip/>
>>>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().
>>
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.
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.
Not every class needs to be a component, and adding too many entries in
cocoon.xconf will be confusing for users. So what about the
"de-Avalonization" of the ElementProcessor (which means remove a useless
Component implementation and an entry in cocoon.xconf) ? Or did I miss
something that really requires it to be a component ?
<snip what="long discussion"/>
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: POI Serialization code committed
Posted by John Morrison <jo...@ntlworld.com>.
Do we have sufficient code &/ reason for a separate
Cocoon-contrib cvs?
J.
> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Thursday, 07 March 2002 10:06 pm
> To: cocoon-dev@xml.apache.org
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by giacomo <gi...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: POI Serialization code committed
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org