Jeremias Maerki wrote:
I'm sure if such a person existed and they wrote their own FOP plug-in they could very easily fix a very small compatibility issue such as this.

Again: it's not the fix that is the problem. It is about
backwards-compatibility and that's an issue mostly for users and release
managers. Developers have an easy life. Imagine what would happen if
Linus Torvalds would constantly change the API for low-level drivers or
if Sun would simply change APIs in their Java class library without
respecting backwards compatibility.

I didn't make a change to a low-level driver used by millions. I made a change to one method signature of one interface that affected one external package used by FOP that you host externally on your own website. I'm sorry that this change meant a small amount of work/support overhead for you, but you are losing perspective here.

I have included the simple 2 line patch file for src/java/org/apache/fop/render/pdf/pdfbox/ Apologies if this creates a little more work for you.
Your patch has one problem: it kills backwards-compatibility for FOP
0.95. I won't delete the old method so this whole thing will still work
with 0.95.
I don't see how this would at all affect 0.95 compatibility.  You already 
provide a cersion 1.2
( which will work just 
fine for 0.95
installations - so no change there. And you also already provide a version 1.1a (from rev 611768 or later), so all that needs to be done once the Temp_AFPGOCAResources branch is merged back into trunk is release a new trunk version with the 2 line patch applied.

Yeah, and after your logic I'll continue to play that game indefinitely.
Each time we release a new FOP, I have to update my plug-in. That's not
my idea of software development.

You know full well that this situation is not to be expected, this was just an exception. My idea of software development doesn't involve spending lots of time trying to score points off each other on a mailing list over quite small issues.

The necessary changes in my plug-in are negligible. What isn't is the
time I'll spend documenting which version of the plug-in the users have
to select for which FOP version. Add to that time I spend on answering
the questions of the people who don't RTFM.
I sympathize, users can be demanding even when you give of your time freely :).

I wonder if you've spent one second thinking about
backwards-compatibility before changing the PDFImageHandler interface.
Quite simply I wasn't aware that your external pdf images package touched upon this interface. Its not part of the FOP code base. I will continue to always want what is best for the health of the project, I find your comment both unnecessarily rude and disrespectful.

It doesn't really matter if I have an external implementation of that
interface or not. The interface was designed as a service provider
interface with dynamic registration. That automatically turns it into an
external interface for FOP which needs to be treated with care.

The PDF renderer doesn't profit from the changes you made. It just
breaks the already existing plug-ins. You've had an idea for the image
handler plug-ins for the AFP Renderer and you wanted to reuse the
registry part. And that's what affects the PDF part. The name clash in
the IF branch is another story. That one is not even so important.

I never claimed that the PDF renderer would profit did I?  But other parts of 
FOP certainly could.

Change happens, yes, improvements happen, too, but the "after me the
Flood" mentality makes my blood boil.

I have no such mentality, you boil your own blood.  I fail to understand
why you continue to blow up small points out of all proportion and attack me in this way. I have worked very hard to improve our AFP support and now you try to provoke me and make things ugly.


Reply via email to