cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)
Date Fri, 10 Aug 2001 05:05:36 GMT
On Thu, 9 Aug 2001, Patel, Mike wrote:

> Hi,
>
> Is this mean that Cocoon will have newer version of FOP built in to it

Yes (at least Cocoon 2).

> and
> if I implementing Cocoon, do I need stand alone version of FOP or not.

The fop.jar was always distributed with Cocoon.

Giacomo

> 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
>
> Thanks,
>
> Mike
>
> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Thursday, August 09, 2001 2:55 PM
> To: 'cocoon-dev@xml.apache.org'
> Cc: fop-dev@xml.apache.org
> 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
> would
> > also submit a patch to Cocoon for it to use the new API so the next
> release
> > 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
> you.
>
> Giacomo
>
>
> >
> > -Steve
> > -----Original Message-----
> > From: Sam Ruby [mailto:rubys@us.ibm.com]
> > Sent: Thursday, August 09, 2001 10:33 AM
> > To: fop-dev@xml.apache.org
> > Cc: cocoon-dev@xml.apache.org
> > 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
> should
> > 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
> arise.
> > 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
> time
> > before change.  As you point out, perhaps this suggestion is premature.
> >
> > - Sam Ruby
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-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
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message