cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From COFFMAN Steven <SCoff...@COVANSYS.com>
Subject RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - C ocoon2)
Date Thu, 09 Aug 2001 15:17:59 GMT
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.

-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


Mime
View raw message