Hi Peter, The public API could be improved but I also don't see in the wiki links a good reason to do so. It is expected to have a stable public API, once a project reaches a 1.0 version. Backwards incompatible changes are expected in a 2.0 version for methods/classes that have been deprecated.
Alex Giotis On Mar 28, 2012, at 9:08 PM, Jeremias Maerki wrote: > Hi Peter, > > can you please explain what problem you're trying to solve? From the > Wiki pages I cannot derive that. And what do you mean by the separation > of configuration and deployment? I'm particularly clueless as to how an > API affects deployment here. > > There must be a really, really good reason to change the frontmost > public API of FOP in a backwards-incompatible way. Changing the API will > cause considerable work for all users when they upgrade. We must not do > that on a whim. > > The current API is the product of long discussions and a positive vote > back in 2005/2006. It was roughly modelled after the JAXP pattern with > TransformerFactory and Transformer. I'd say that the API has proven to > be solid over the years. > > For reference: > http://wiki.apache.org/xmlgraphics-fop/ApiRequirements > http://wiki.apache.org/xmlgraphics-fop/ApiDesign > > On 28.03.2012 12:02:27 Peter Hancock wrote: >> Hello, >> >> As part of our work addressing URI resolution in FOP [1], Mehdi and >> myself have been considering making changes to the configuration and >> deployment of FOP. Our proposal will introduce breaking changes to >> the public API that will affect code that embeds FOP. Please review >> our proposal [2] and provide feedback. >> >> Thanks, >> >> Peter >> >> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution >> [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration > > > > > Jeremias Maerki >
