You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ba...@nicolaken.com> on 2002/01/11 09:41:20 UTC
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
----- Original Message -----
From: "Morrison, John" <Jo...@uk.experian.com>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 9:28 AM
Subject: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
> Hi,
>
> Should the authors (Marc Johnson and Andrew C Oliver I believe are the two
> people of note) of POI get CVS commit rights?
POI development cycle is *very* fast.
I've been working with them for some time, and IMO they should be able to
commit on their own.
If they cannot, you will have to deal with loads of daily patches ;-)
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
Posted by "Andrew C. Oliver" <ac...@nc.rr.com>.
Hi All,
I see the discussion has gotten a bit more lively as I was asleep. I'd
like to address the concerns directly.
The donation is a Serializer and very shortly a Generator and those
generators/serializers that roll out as the MS Word effort pipes up.
The problem was shared code between the generator and serializer could
not be capitalized upon in the format it was in without some very nasty
cross package import statements. Nor could the common serialization
code that will be used for ALL POI-based serializers be capitalized on.
This was mostly a packaging issue, but Ken also had some great ideas
that will help us down the road. The code was designed to be shared,
just not packaged as such.
I don't foresee this happening again. Its a matter of the project
vision has expanded (to keep us busy) and the infrastructure had to as
well.
My attitude toward the generators and serializers is that they should
happen early on in and late in the development cycle of POI. (We're
very iterative). Marc's serialization framework makes it very easy to
add new things to the serializer and I like to see this kind of work
done at the end of the cycle when the API is frozen or at the beginning
(like now) to "catch up" to the API.
So the plan is "release early and release often" for the development
code and always have a stable build which occasionally gets bug fixes.
Think of it as Cocoon 2.1-dev versus 2.0. The builds almost always
work, the unit tests keep us in line and the work on the API moves along
while the serializer work happens at the beginning and end of the
project.
I basically agree with your philosophy of updating the jars on occasion
and the serializer at the same time. I'd like to talk more on how to
divide this into a stable and development branch should we move
forward. I don't think there is any real disagreement here.
-Andy
PS There is other development that you don't see in the commit logs,
happening right now as well. We are collaborating with the responsible
developer from OpenOffice.org to fully document the Excel File format.
I intent to do the same for the Word File Format which is gearing up
shortly. We wrote the schema for gnumeric (needed the documentation)
and will be help making sure it stays up to date (but the gnumeric folks
are responsible for it).
On Fri, 2002-01-11 at 07:05, Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
> >
> > ----- Original Message -----
> > From: "Gianugo Rabellino" <gi...@apache.org>
> > To: <co...@xml.apache.org>
> > Sent: Friday, January 11, 2002 10:09 AM
> > Subject: Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
> > serializers/generators)
> >
> > > Nicola Ken Barozzi wrote:
> > >
> > > >
> > > > POI development cycle is *very* fast.
> > > > I've been working with them for some time, and IMO they should be able
> > to
> > > > commit on their own.
> > > > If they cannot, you will have to deal with loads of daily patches ;-)
> > >
> > >
> > > This kinda worries me. As far as Cocoon is concerned this donation turns
> > > out to be a serializer, which most probably (but I haven't seen it yet)
> > > should be a little more than a wrapper to some POI driver.
> >
> > There is also a new framework that is used to serialize easily file formats
> > for POI.
> >
> > > If the API is
> > > not stable this might be an issue given that Cocoon is advertised as
> > > production-ready and robust (true, we use other unstable and sometimes
> > > experimental stuff, Avalon being the most notable example, but this is
> > > in a controlled environment).
> >
> > To be clear, the *only* contract there is with Cocoon is the configuration
> > and the XML input-output.
> > The XML format is Gnumeric 1.0, Andy is doing the necessary validation of it
> > in unit tests with the schema he wrote.
> > Apart from this, Cocoon doesn't care if internal APIs change.
> >
> > > Don't get me wrong, I'm really happy about POI being part of the game,
> > > but I'd like to have a good reason for having tons of daily patches
> > > coming in, or as far as I'm concerned they will be confined to
> > > scratchpad for a long time. :-)
> >
> > IMHO think it's unfair, given the importance of the project.
> > POI is in 1.0 version, I don't think you will want it in scratchpad for
> > long, as many users will be asking continuously how to install it.
> > My 2cents, of course ;-)
> >
> > > In short: I'm absolutely in favor of giving the POI team commit access,
> > > but I'd love to see them updating (not too often :)) the poi jars and
> > > work on the Cocoon wrappers mostly if not only for bugfixing once they
> > > make into production (out from the scratchpad). They should be aware of
> > > back compatible issues in case they have to change the API (this is
> > > nothing different from the actual situation, I just wanted to make
> > > myself clear).
> >
> > +1 There are complete unit tests integrated in the ant build, and Gump will
> > help guarantee that the contracts are kept.
> > The fact is that bugfixes are very very frequent, 'cause we're dealing with
> > an undocumented (badly anyway) file format and many M$ product versions.
>
> Easy, Ken.
>
> Gianugo, was simply stating worries about a too-fast release cycle on
> the contracts.
>
> But I've asked Andrew that myself and I think the serializer won't
> require that many changes so I think everybody is happy.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 1:05 PM
Subject: Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
> Easy, Ken.
:-)
> Gianugo, was simply stating worries about a too-fast release cycle on
> the contracts.
Yes, I agree.
I hope I was clear enough in my explanation that the contracts are intended
to be as stable as possible; IMHO that means at most possibly one change per
distribution.
Anyway none are expected now that Gnumeric has a final format and Andy has
already formalized their schema.
> But I've asked Andrew that myself and I think the serializer won't
> require that many changes so I think everybody is happy.
Yes, I know, I'm collaborating with them in what I can do to help them
integrate in Cocoon.
I stupidly forgot to remember all of you that we recently refactored the
code to separate the generic serialization framework from the serializer
implementations and the java APIs. Only the implementation will require
frequent patches IMO, but this doesn't necessarily have to touch the code in
Cocoon.
Anyway I know, from my brief but intense experience with them, that they
value continuity and stability of contracts very much. Andy sure knows how
to defend himself, when he wakes up ;-) .
Sorry Gianugo if I've given you the impression of being polemic, it wasn't
in my intentions. You know what it's like to be a project manager ;-)
IMO this discussion brought up a need, that I always have in programs: the
need of auditing contracts.
They have to be first defined, then controlled. JUnit can help in this; does
GUMP run now multiple build targets?
How should Cocoon define and control-audit-enforce contracts?
If we want clear contracts, we must first write them.
And contract enforcement is the first step to quality (ISO9000 sense) of the
code.
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> ----- Original Message -----
> From: "Gianugo Rabellino" <gi...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Friday, January 11, 2002 10:09 AM
> Subject: Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
> serializers/generators)
>
> > Nicola Ken Barozzi wrote:
> >
> > >
> > > POI development cycle is *very* fast.
> > > I've been working with them for some time, and IMO they should be able
> to
> > > commit on their own.
> > > If they cannot, you will have to deal with loads of daily patches ;-)
> >
> >
> > This kinda worries me. As far as Cocoon is concerned this donation turns
> > out to be a serializer, which most probably (but I haven't seen it yet)
> > should be a little more than a wrapper to some POI driver.
>
> There is also a new framework that is used to serialize easily file formats
> for POI.
>
> > If the API is
> > not stable this might be an issue given that Cocoon is advertised as
> > production-ready and robust (true, we use other unstable and sometimes
> > experimental stuff, Avalon being the most notable example, but this is
> > in a controlled environment).
>
> To be clear, the *only* contract there is with Cocoon is the configuration
> and the XML input-output.
> The XML format is Gnumeric 1.0, Andy is doing the necessary validation of it
> in unit tests with the schema he wrote.
> Apart from this, Cocoon doesn't care if internal APIs change.
>
> > Don't get me wrong, I'm really happy about POI being part of the game,
> > but I'd like to have a good reason for having tons of daily patches
> > coming in, or as far as I'm concerned they will be confined to
> > scratchpad for a long time. :-)
>
> IMHO think it's unfair, given the importance of the project.
> POI is in 1.0 version, I don't think you will want it in scratchpad for
> long, as many users will be asking continuously how to install it.
> My 2cents, of course ;-)
>
> > In short: I'm absolutely in favor of giving the POI team commit access,
> > but I'd love to see them updating (not too often :)) the poi jars and
> > work on the Cocoon wrappers mostly if not only for bugfixing once they
> > make into production (out from the scratchpad). They should be aware of
> > back compatible issues in case they have to change the API (this is
> > nothing different from the actual situation, I just wanted to make
> > myself clear).
>
> +1 There are complete unit tests integrated in the ant build, and Gump will
> help guarantee that the contracts are kept.
> The fact is that bugfixes are very very frequent, 'cause we're dealing with
> an undocumented (badly anyway) file format and many M$ product versions.
Easy, Ken.
Gianugo, was simply stating worries about a too-fast release cycle on
the contracts.
But I've asked Andrew that myself and I think the serializer won't
require that many changes so I think everybody is happy.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
Posted by "Andrew C. Oliver" <ac...@nc.rr.com>.
On Fri, 2002-01-11 at 05:35, Gianugo Rabellino wrote:
> Nicola Ken Barozzi wrote:
>
> >>Don't get me wrong, I'm really happy about POI being part of the game,
> >>but I'd like to have a good reason for having tons of daily patches
> >>coming in, or as far as I'm concerned they will be confined to
> >>scratchpad for a long time. :-)
> >>
> >
> > IMHO think it's unfair, given the importance of the project.
> > POI is in 1.0 version, I don't think you will want it in scratchpad for
> > long, as many users will be asking continuously how to install it.
> > My 2cents, of course ;-)
>
>
> This (IMNSHO ;)) is perfectly fair to users. I agree and wish that many
> people will be using it, yet if the thing is going through such a
> massive bugfixing as the one you are outlining:
>
> > The fact is that bugfixes are very very frequent, 'cause we're
> > dealing with an undocumented (badly anyway) file format and
> > many M$ product versions.
>
Ken: Whoa? Bugfixes are frequent? How come no one told me?..
Seriously we've had 1 minor, 1 major, and one trivial MS-blameable issue
since the stable release.
These would not have gotten us to 1.0.2 except that the minor bug was
reported just as the 1.0.1 announcement was going out. I think it is
unfair to characterize this as "very very frequent".
Secondly, these were ALL API issues and none were serializer issues.
I disagree with Ken that MS was to blame for these (except for the
trivial issue). I blame 1.0 releases and production data for these
:-D. The two more serious bugs were in the Static String table (in
short cells contain a reference to a blocked set of string data).
Getting this algorythm right was very difficult and testing was very
extensive. That being said: nothing breaks code like REAL world data.
Had we not done a 1.0.0 release, then these would have NEVER been
discovered (well Marc feels we should have had a super duper long string
unit test, but I consoled him, no use in crying over spilled milk).
We had a second bugfix release because the first was on its way out the
door as while other was being reported. The bug covered in the 1.0.1
was more serious and intermittent and I absolutely HATE intermittent
bugs so we decided to go ahead and ship it (1.0.1), while we fixed the
more minor bug which only affected people who write longer strings then
this email into a single cell (which I would bet/hope is a minority
:-p), but it was important to "get it right" in the production code. So
both were in the same area of (API) code, and it is the one of the most
complex pieces of the whole thing. (If anyone wants to know more, just
ask. I just don't know everyone finds this as interesting as I do and
I'm trying not to get sidetracked in my emails :-D)
I posted a very trivial patch to the poi-users list before the 1.0.2 was
released (though it was in testing mode), due to a Microsoft Office
service pack issue. Meaning, my stock version doesn't do this (I run it
through VMWare...I'm 100% UNIX/Linux to the core of my cold dark black
soul :-D). The issue being an annoying dialog box comes up and says
there is a potential security issue with POI::HSSF generated files.
This was a single boolean value change and does not warrant another
bugfix release. (We'll queue this and any other issues and do one
sometime midway though the development cycle). While I can't justify a
release for a boolean value change :-) I had to sympathize with some
poor guy like me whose user-community asks him if the reporting system
he wrote is sending them viruses so the patch is available to those who
need it.
> this makes me wonder why POI is labeled as 1.0 if there is such a huge
> amount of needed patches going on... in second place this might lead to
> undesired countereffects, with users having to resort to CVS updates to
> get a working Cocoon+POI setup. In other words: are we targeting users
> (which means stable tree + included jars) or developers/hackers? If we
> go for the second than people that can use CVS can also live with a
> scratchpad component.
>
My answer: both if you're talking about the APIs (this is very confusing
for the moment). We have 2 branches. Stable and Development just like
Cocoon does. The POI user community is not particularly patient. We're
working on adding formula support to HSSF (for 2.0) and people are
writing asking if we can skip that and just go straight to Pivot tables
:-p. So the development builds of the API are there to those who need
them.
For the serializer: I'm not opposed to doing hacker releases if someone
can convince me that there is a compelling reason to do so, but my focus
is to get the APIs stable for each release then expose the APIs via the
serializers and generators. While thats just my opinion I think it is
the general consensus in the POI family :-D.
I even go so far as to keep the Serializer and generator a bit behind
the API. My "wearing the user-hat" perspective of this is that I'd
rather have something WORK reliably or not be provided at all when I'm
working in XML. Our API user community tends to use the development
builds and flush out bugs very fast and for that we are very grateful.
This greatly adds to the stability of the serializer provided it is kept
a little behind.
The only reason I can think of for a hacker release is some new concept
or something. This won't happen for some time I suspect. Once we run
out of challenging things to do.... maybe a Batik (which is very very
cool IMNSHO) -> POI Serializers bridge that lets you embed Batik images
in M$ documents.. But we're not out of hard stuff to do yet.. (though
that sounds like a lot of fun :-p)... Maybe if some Batik guy comes
along and needs something to do.... Okay I'm sidetracked.
> Again, I don't want to be harsh and I want you to understand that I'm
> all in POI's side. It's just that every reply that you give worries me
> even more :)
>
+1. The reply he gave worried me too :-D. Perhaps Ken's confused
between the Beta, Production and Development releases. Our Beta of the
serializer had some serious issues and Ken was instrumental in resolving
those with some great test cases and some samples. This all happened
somewhat quickly around the time he became heavily involved so it may
have looked like the turmoil was the norm when it was just that lovely
phase transition from Beta to release to first development build and
maintenance release mode. He is correct that POI has a very quick
development cycle. We also are very big on iterative development (so
you will see lots of patches to the API in the development build rattle
through in a short period of time).
Worry not, the "stable" build is stable, the serializer has NOT been
changed SINCE the release. Working on the Serializer and Generator is
soooo easy due to Marc's POIFS-Serializers framework. The changes we
did in the last week were a one time shoring up for having multiple
serializers for multiple formats and sharing serializer constructs with
the generators. (element stuff)
ciao,
Andy
> Ciao,
>
> --
> Gianugo
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Gianugo Rabellino <gi...@rabellino.it>.
Nicola Ken Barozzi wrote:
>> Again, I don't want to be harsh
> Doesn't seem [;-)]
Now Ken, let's try to set things straight: I was already replying to
John's email with a solid +1 when your email came through stating that
we would be better giving CVS access to the POI guys or, given the
attitude of developers and the activities needed to care this baby, we
would have been blasted "daily" by "lots of patches".
This rang a bell in my head: I do think that POI support would be a
great addition to Cocoon (and, BTW, one of my main interests in this
community has been and still is integration of new and interesting
technologies in Cocoon, e.g. JFOR and XML:DB), but I was worried reading
from your emails that, while the real one to blame is MS and not the POI
team, POI needs continous care and feeding. Now, this is Cocoon
development and I'm more than happy in having Cocoon leverage new and
useful technologies like POI. But this doesn't mean that development of
such technologies should happen in the Cocoon CVS. :-)
Anyway, Stefano just gave me the reply I wanted, so I'm perfectly happy,
here is another +1 just in case, and this is over :)
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Gianugo Rabellino" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 11:35 AM
Subject: Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
> Nicola Ken Barozzi wrote:
>
> >>Don't get me wrong, I'm really happy about POI being part of the game,
> >>but I'd like to have a good reason for having tons of daily patches
> >>coming in, or as far as I'm concerned they will be confined to
> >>scratchpad for a long time. :-)
> >
> > IMHO think it's unfair, given the importance of the project.
> > POI is in 1.0 version, I don't think you will want it in scratchpad for
> > long, as many users will be asking continuously how to install it.
> > My 2cents, of course ;-)
>
> This (IMNSHO ;)) is perfectly fair to users. I agree and wish that many
> people will be using it, yet if the thing is going through such a
> massive bugfixing as the one you are outlining:
>
> > The fact is that bugfixes are very very frequent, 'cause we're
> > dealing with an undocumented (badly anyway) file format and
> > many M$ product versions.
>
> this makes me wonder why POI is labeled as 1.0 if there is such a huge
> amount of needed patches going on...
By "needed", what do you mean?
The fact is that real-life scenarios are so varied that there are many
"special" cases that can come up. Ever tried using M$ product versions with
differrent M$ oses? ;-)
> in second place this might lead to
> undesired countereffects, with users having to resort to CVS updates to
> get a working Cocoon+POI setup.
? This is riduculous. ;-) *Any* user that has a particular bug that gets
fixed resorts to the CVS version.
This happens with any component. What makes POI special in this regard?
> In other words: are we targeting users
> (which means stable tree + included jars) or developers/hackers?
You are jumping to conclusions.
We are targetting USERS. Who use ;-) the code and need bugfixes. The fact
that they can be frequent doesn't mean it's not stable. It can also mean
that bugs are reported more.
> If we
> go for the second than people that can use CVS can also live with a
> scratchpad component.
> Again, I don't want to be harsh
Doesn't seem ;-)
> and I want you to understand that I'm
> all in POI's side. It's just that every reply that you give worries me
> even more :)
:-)
Just don't jump to conclusion.
POI works and many users use it.
PERIOD.
Contracts are defined and will be kept.
PERIOD.
Advanced-dev portions like the DOC format stuff are going absolutely in
scratchpad.
PERIOD.
Makes sense.
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Gianugo Rabellino <gi...@apache.org>.
Nicola Ken Barozzi wrote:
>>Don't get me wrong, I'm really happy about POI being part of the game,
>>but I'd like to have a good reason for having tons of daily patches
>>coming in, or as far as I'm concerned they will be confined to
>>scratchpad for a long time. :-)
>>
>
> IMHO think it's unfair, given the importance of the project.
> POI is in 1.0 version, I don't think you will want it in scratchpad for
> long, as many users will be asking continuously how to install it.
> My 2cents, of course ;-)
This (IMNSHO ;)) is perfectly fair to users. I agree and wish that many
people will be using it, yet if the thing is going through such a
massive bugfixing as the one you are outlining:
> The fact is that bugfixes are very very frequent, 'cause we're
> dealing with an undocumented (badly anyway) file format and
> many M$ product versions.
this makes me wonder why POI is labeled as 1.0 if there is such a huge
amount of needed patches going on... in second place this might lead to
undesired countereffects, with users having to resort to CVS updates to
get a working Cocoon+POI setup. In other words: are we targeting users
(which means stable tree + included jars) or developers/hackers? If we
go for the second than people that can use CVS can also live with a
scratchpad component.
Again, I don't want to be harsh and I want you to understand that I'm
all in POI's side. It's just that every reply that you give worries me
even more :)
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Gianugo Rabellino" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, January 11, 2002 10:09 AM
Subject: Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI
serializers/generators)
> Nicola Ken Barozzi wrote:
>
> >
> > POI development cycle is *very* fast.
> > I've been working with them for some time, and IMO they should be able
to
> > commit on their own.
> > If they cannot, you will have to deal with loads of daily patches ;-)
>
>
> This kinda worries me. As far as Cocoon is concerned this donation turns
> out to be a serializer, which most probably (but I haven't seen it yet)
> should be a little more than a wrapper to some POI driver.
There is also a new framework that is used to serialize easily file formats
for POI.
> If the API is
> not stable this might be an issue given that Cocoon is advertised as
> production-ready and robust (true, we use other unstable and sometimes
> experimental stuff, Avalon being the most notable example, but this is
> in a controlled environment).
To be clear, the *only* contract there is with Cocoon is the configuration
and the XML input-output.
The XML format is Gnumeric 1.0, Andy is doing the necessary validation of it
in unit tests with the schema he wrote.
Apart from this, Cocoon doesn't care if internal APIs change.
> Don't get me wrong, I'm really happy about POI being part of the game,
> but I'd like to have a good reason for having tons of daily patches
> coming in, or as far as I'm concerned they will be confined to
> scratchpad for a long time. :-)
IMHO think it's unfair, given the importance of the project.
POI is in 1.0 version, I don't think you will want it in scratchpad for
long, as many users will be asking continuously how to install it.
My 2cents, of course ;-)
> In short: I'm absolutely in favor of giving the POI team commit access,
> but I'd love to see them updating (not too often :)) the poi jars and
> work on the Cocoon wrappers mostly if not only for bugfixing once they
> make into production (out from the scratchpad). They should be aware of
> back compatible issues in case they have to change the API (this is
> nothing different from the actual situation, I just wanted to make
> myself clear).
+1 There are complete unit tests integrated in the ant build, and Gump will
help guarantee that the contracts are kept.
The fact is that bugfixes are very very frequent, 'cause we're dealing with
an undocumented (badly anyway) file format and many M$ product versions.
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)
Posted by Gianugo Rabellino <gi...@apache.org>.
Nicola Ken Barozzi wrote:
>>Should the authors (Marc Johnson and Andrew C Oliver I believe are the two
>>people of note) of POI get CVS commit rights?
>>
>
> POI development cycle is *very* fast.
> I've been working with them for some time, and IMO they should be able to
> commit on their own.
> If they cannot, you will have to deal with loads of daily patches ;-)
This kinda worries me. As far as Cocoon is concerned this donation turns
out to be a serializer, which most probably (but I haven't seen it yet)
should be a little more than a wrapper to some POI driver. If the API is
not stable this might be an issue given that Cocoon is advertised as
production-ready and robust (true, we use other unstable and sometimes
experimental stuff, Avalon being the most notable example, but this is
in a controlled environment).
Don't get me wrong, I'm really happy about POI being part of the game,
but I'd like to have a good reason for having tons of daily patches
coming in, or as far as I'm concerned they will be confined to
scratchpad for a long time. :-)
In short: I'm absolutely in favor of giving the POI team commit access,
but I'd love to see them updating (not too often :)) the poi jars and
work on the Cocoon wrappers mostly if not only for bugfixing once they
make into production (out from the scratchpad). They should be aware of
back compatible issues in case they have to change the API (this is
nothing different from the actual situation, I just wanted to make
myself clear).
Feedback from the POI devs is most appreciated of course :)
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org