Remove legacy PDFURIResolver class

Development
#1

Hi devs,

While extracting out the Formula Macro, I’ve had to refactor the PDF export. In particular PDFResourceResolver. Prior to FOP 2.0 we were using a PDFURIResolver and that was dropped when moving to FOP 2.0 (replaced by PDFResourceResolver), by moving it to legacy.

Note that it’s located in an impl package name.

I could keep it but it means changing its implementation and I don’t like changing legacy code’s implementation. There are also no test and it’s going to be hard to test since it’s not used anymore by FOP since a long time ago. So I think it’s a lot of work and risk for not much.

This is why I’m sending this vote to drop backward compatibility for it:

  • it’s old now
  • it’s in an impl package
  • it’s very unlikely it’s used by any extension/custom code

Note: I’m sending this vote to comply with Development Practices - XWiki

Here’s my +1

Thanks

Remove TexAction component
What do we do with Mathjax macro vs Formula macro in XS?
#2

Those are not really criteria to get rid of a legacy class.

It seems to be the main reason why it’s OK to remove it is that it simply cannot really be used with the current version of FOP anyway, so anything that use it is most probably broken anyway, so I’m fine with it.

#3

They are related, because when you decide to break backward compatibility you need to explain why it’s ok to break users and thus you need to find out how many will be impacted. These 2 points reduce the likelihood that there are users using it.

I’m considering this a +1 then :wink:

Thx