cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patel, Mike" <>
Subject RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)
Date Fri, 10 Aug 2001 00:07:43 GMT

Is this mean that Cocoon will have newer version of FOP built in to it and
if I implementing Cocoon, do I need stand alone version of FOP or not.  I
also want to thank all of you folks out their and all of you are doing great
job in helping user community out.

Thanks in advance



-----Original Message-----
From: giacomo []
Sent: Thursday, August 09, 2001 2:55 PM
To: ''
Subject: RE: Public API Change in Driver (Was Re: [GUMP] Build Failure -
C ocoon2)

On Thu, 9 Aug 2001, COFFMAN Steven wrote:

> We are very comitted to keeping all FOP and Cocoon releases in sync. When
> Cocoon changes Xerces and Xalan versions and JDK versions, so does FOP.
> We plan on making a new release of FOP this weekend, and at minimum we
> also submit a patch to Cocoon for it to use the new API so the next
> of Cocoon2 would sync with FOP.
> FOP underwent some major refactoring to massively reduce memory usage, and
> it might not be possible to make a workable deprecated API for backwards
> compatibility. (Mark?) We don't break API compatibility lightly, and don't
> expect to have to do so again in the foreseeable future. Sorry for not
> posting to Cocoon-dev earlier what was up.

Steven, thanks for the information. As Cocoon uses FOP in a
serialisation phase of resource production it is not very harmfull to us
as long as FOP's functionallity remains the same (we'll get in trouble
if you would cancel SAX support :) But sure we'd like to stay in sync.
Submitting a patch to the FOPSerializer will be very generous, thank


> -Steve
> -----Original Message-----
> From: Sam Ruby []
> Sent: Thursday, August 09, 2001 10:33 AM
> To:
> Cc:
> Subject: Re: Public API Change in Driver (Was Re: [GUMP] Build Failure -
> Cocoon2)
> Weiqi Gao wrote:
> >
> > Sam Ruby wrote:
> > >
> > > It appears that some fop interfaces are changing in a way that
> > > will impact cocoon2... is there work underway to keep these
> > > projects in synch?
> > >
> > > In particular, is there another backwards compatible set of
> > > interfaces that cocoon2 should be using during the transistion?
> >
> > This is probably introduced by Mark's patch.  I have reported this in my
> > report when I tested the patch before the commit (See the thread "FOP in
> a
> > servlet under load").  Mark mentioned it in his web site for the patch
> too.
> >
> > The documentation ("Embedding") should probably be updated by the
> committers
> > to reflect the change.
> >
> > I don't think a backwards compatible interface is needed.  Not for
> something
> > with a version number of 0.19.0, and been characterized as pre-beta,
> > not-production-ready and incomplete.  (If that doesn't buy the project
> the
> > rights to change the public interface at will, we might as well call it
> > version 1.0).
> I realize that xml-fop is one of those projects which is perennially in
> alpha.  What I am looking for is concrete suggestions on how Cocoon2
> deal with this state.
> One possibility is that cocoon2 should drop support for FOP.  I think that
> that would be unfortunate.
> Another possibility is that cocoon2 monitor for changes in the public API
> and engages in a dialog to resolve any issues that come up when they
> I am doing the former, and trying to spark an interest in the latter.
> A third possibility is for fop to deprecate interfaces for a period of
> before change.  As you point out, perhaps this suggestion is premature.
> - Sam Ruby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

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

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

View raw message