Re: [vote] POI commiters (was: RE: [vote] Accepting donated POI serializers/generators)

["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