Looks like your message simply got stuck in the moderator's queue. On 30.05.2003 18:17:31 Thomas DeWeeese wrote: > Jeremias Maerki wrote: > > >Hi Batik-Devs, > > > >the latest changes in Batik broke both the maintenance branch and HEAD > >of FOP: > > > >http://cvs.apache.org/builds/gump/2003-05-30/xml-fop.html > >http://cvs.apache.org/builds/gump/2003-05-30/xml-fop-maintenance.html > > > >Is there any possibility to adjust the changes so they don't break > >third-party dependencies? > > > It would be possible to define > AbstractGraphicsNode.getSensitiveBounds to return > what ever AbstractGraphicsNode.getPrimitiveBounds would return, but I > would rather leave it as > an abstract method because just like the other bounds methods people who > derive should > give careful consideration to the proper value to return for the > specific type of graphics node > involved. The additional method is required for proper support of > pointer-events in SVG.
I see your point. > In this case it is very simple to define the method (it should I > think just return getPrimitiveBounds). That's true and I'm going to do that. However, I'm worrying about binary compatibility. At the moment we have to tell our users that they have to use the Batik-version delivered with FOP. I'd like to see Batik's API stabilize some more so people can just download the latest version of Batik and replace it in their installation. I realize that FOP is a somehat special Batik customer from an API-POV. But let's take Cocoon: It contains blocks for Batik and FOP (where FOP uses Batik for SVG support). If a Cocoon user needs to use Batik (for generating SVG) and FOP (for generating PDF containing SVG graphics) this user is constrained to use the Batik version that FOP was compiled with. He cannot simply upgrade his Batik version to avoid a bug, for example. The very least he has to do is recompile FOP with that specific version of Batik he wants to use. Hopefully it compiles. To illustrate: A few minutes ago a took FOP 0.20.5rc3a and put in batik-all.jar (built from CVS today). It turns out that binary compatibility got broken in March already: http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/bridge/UnitProcessor.java.diff?r1=1.10&r2=1.11&diff_format=h I got the following when running FOP (without recompile because this would have solved the problem): Exception in thread "main" java.lang.NoSuchMethodError: org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/util/UnitProcessor$Context; at org.apache.fop.svg.SVGElement.layout(SVGElement.java:218) As I said before, the FOP teams "produced" similar problems in the past. After a recent problem between Cocoon and FOP I'm committed to watching over FOP's APIs. I'm hoping that the Batik team will similarly watch over what happens in their APIs. > BTW perhaps I'm missing the point of the 'maintence' build but > shouldn't that be done off > one of the release versions of Batik? I'm under the impression that Gump is intended to check code-compatibility between projects in CVS, not against released versions. This is to have an early warning about incompatible changes (before a release), so they can be resolved (hopefully with a compatibility layer) before the release. With my findings above I think it would even make sense to have an additional mechanism to check binary compatibility (just some runtime tests using JUnit, for example) between projects (CVS of project 1 against release xy of project 2). FOP's maintenance branch is where our latest release candidate originated. FOP 0.20.5 will also be based on the maintenance branch. The trunk of the xml-fop CVS module is home of our redesign effort. This is also the place where you get the PDF transcoder from because that's where Keiron Liddle has done a lot of refactoring work for the SVG support. So, we have two lines of development. After the 0.20.5 release the maintenance branch will be frozen. More details here: http://xml.apache.org/fop/dev/ Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
