RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)

["Patel, Mike" <mi...@pacificlife.com>]

Hi,

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

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

RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)

[giacomo <gi...@apache.org>]

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

RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)

[giacomo <gi...@apache.org>]

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org