I would like to raise an issue about this. I am not complaining, just
pointing out some things.
I Fop is updated to comply with the api in the current batik cvs then fop
will only work with that cvs build.
So for example if a release of fop is made in the meantime (eg. 0.20.1 and
0.20.2) then they will only work with the batik version that comes with the
build. It is not possible for the user to get the latest version of batik,
for example batik 1.1, when it comes out and use that.
It might be possible to release a new version of fop but this is a bit more
difficult and time consuming in our current situation.
This gets worse when another project is using fop and batik (eg. cocoon)
and may also be updating the jars at various times.
Realistically a "proper" version of fop can only be released along with a
stablised api version of batik.
It seems that keeping up to date with cvs of other libs doesn't always
solve any problems and may actually create some.
On 2001.10.25 13:14 Sam Ruby wrote:
> [javac]
>/home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg/SVGUserAgent.java:37:
> class org.apache.fop.svg.SVGUserAgent must be declared abstract. It does
> not define boolean isXMLParserValidating() from interface
> org.apache.batik.bridge.UserAgent.
> [javac] public class SVGUserAgent implements UserAgent {
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
