Vincent Hardy wrote: > > I did not realize that FOP was building off our CVS repository. We > publish a change log with our releases and the major change Thierry > and Thomas are working on will be detailed in the next developer > release.
Just to clarify - FOP may or not be building off of the xml-batik CVS repository, but I do. The reason why I do is exactly to provide early warning of such impending changes in order to promote discussion. > What is happening is that we are fixing what we think was a design > error and we are removing a parameter from a large number of methods > in GVT, one of the core Batik modules. You are right, we are not > deprecating the old signature, even though I agree deprecation is > good practice. You are also adding a parameter to a fair number of methods. Note that in this case, we are discussing an interface, so it is not clear that deprecation of methods is an effective means of providing backwards compatibility. Any additions or changes will require source code changes to implementors of this interface. > However, our change being such a wide change (i.e., > there is a very large number of methods impacted), we think we > should bite the bullet now and go on with a cleaner, leander API. > There is inconvenience for some users (FOP is one), and we are sorry > about it. Note, however, that this is not an API change in the > most widely used Batik APIs (it is fair to qualify > extending the TextPainter interface as a very advanced Batik > API usage, but of course, this is not any argument for making that > job even more difficult). One thing that works in some occasions is to rename the interface, and for a period of time support both the old and new interface. > Here is what I suggest: > > a. Short term, build using the batik 1.1rc2 release. > b. Wait until Thomas completes the wide-spread changes Thierry has > started (this will further impact the TextPainter interface). > c. Once the API is stable again, update your TextPainter implementation > so that it no longer uses GraphicsNodeRenderContext. > d. Then, you can either use the Batik CVS again or use our next > developer release. The thing to consider here is that often batik and fop are often used in combinations with other components. An example I mentioned in my previous e-mail was cocoon. Even after the next release of batik, cocoon may need to hold back support for this new release lest it steps up to a release that fop does not support. And even cocoon is a component that others may choose to build upon. In general, it is not possible to coordinate the upgrade of every user of an open source project. The overall strategy which I recommend is that every time a breaking change is required, try to have at least one public release in which both the old and new interfaces are supported, with the old interfaces deprecated. - Sam Ruby --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
