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

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

Reply via email to