xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Levinson <Jonathan.Levin...@intersystems.com>
Subject RE: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/org/apache/fop/render/awt/ src/java/org/apache/fop
Date Mon, 23 Jan 2012 18:38:37 GMT
I have no vote, but I’m not happy with the change since it will break our RenderServer.jar
which is a client-server we use for giving rendering tasks to FOP.
In the worst case, we will have to build two versions of the jar – one for fop 1.0 and the
other for people who are using trunk.  This is far from ideal.
A software contract is a software contract.  Once it has been set, and is in the field. it
should be adhered to unless there are powerful overriding reasons that compel a change.

Best Regards,
Jonathan Levinson
Senior Software Developer
Object Group
InterSystems
+1 617-621-0600

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Monday, January 23, 2012 1:22 PM
To: fop-dev@xmlgraphics.apache.org
Cc: mehdi
Subject: Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/
examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/
src/java/org/apache/fop/render/awt/ src/java/org/apache/fop

I'm disturbed that such a change has been committed without a public discussion of the merits,
risks, etc., of making such a breaking change.

Please revert this commit, conduct a public discussion, then, based on the results, implement
the consensus. I have no idea if there is a consensus for this change without having a discussion.

Regards,
Glenn
On Mon, Jan 23, 2012 at 9:15 AM, <mehdi@apache.org<mailto:mehdi@apache.org>> wrote:
Author: mehdi
Date: Mon Jan 23 16:15:23 2012
New Revision: 1234877

URL: http://svn.apache.org/viewvc?rev=1234877&view=rev
Log:
Moved the FOUserAgent into the constructor of the Renderers

This breaks the public API but for good reasons:
1) the user-agent is essential for configuring the renderers
2) instantiation of the constructor is always followed by call to "setUserAgent()" (in the
examples)
3) simplifies the API and reduces mutability of the Renderers

Mime
View raw message