Deprecate old PDF export and retire it?

Development
,
#1

Hi devs,

It’s now been more than one cycle that the new PDF export has been available (since 14.2) and we need to decide what we do with the old PDF export. Right now there are still 48 issues open for it at Loading...

I’m proposing that:

  • We officially declare it a deprecated feature, i.e. we (the XWiki Dev team) stop supporting it. This means closing as won’t fix all issues from Loading... that don’t affect the new PDF export and for those that do, simply remove the “oldcore - PDF Export” component.
  • We either move it Contrib or move it to the Attic
    • It might be a bit too early to move it to the Attic so we might want to first move it to Contrib and create a jira project for it, copying issues (maybe limited to bugs only) from Loading...
    • Since it’s been there for long it’s possible some of our users have complex setups or custom code for the old PDF export and they’d prefer to see it moved as a contrib extension where community members may want to continue working on it.

WDYT?

Thanks

#2

+1 to move it to Contrib

To enter a little more into technical detail, It includes everything which rely on the FOP based export framework, right ?

#3

I haven’t really thought about it. Let’s try to be more precise. Here’s what I’ve found by doing a quick search:

So indeed in this list there’s the FOP part too. I don’t see a need to keep it for now and if we ever need it in the future, we could rewrite it but based on components.

The hard parts are probably:

  • the “Modify” parts for which we would need to keep some backward-compatibility
  • retain the ability to re-install the old PDF export in an XWiki instance in a way that’s not too hard
#4

One piece of info, for the past 1 year we’ve fixed 3 issues that were affecting the old PDF export: Loading...

  • one security issue
  • one regression
  • one bug

And two more bugs if we extend to the last 2 years: Loading...

#5

Regarding the timing of the move, I don’t think it matters much if the chosen solution is to move to contrib, as users will still be able to use it. OTOH if we are forced to break APIs then it’s probably best to do that in 16.0+.

Even if we decide to postpone the move to 16.0, we can still declare it as deprecated once this proposal is agreed, and not supported anymore (or rather minimal support = blocker bugs - this includes regressions and important security issues), even if the code remains in the platform for a while. This would allow us to close the jira issues as won’t fix + update the various docs to mark it deprecated.

#6

Note that at least two of the three issues were not just affecting PDF export but also the office export that shares code with the old PDF export.

#7

Yes, the office export shares code with the old PDF export, so we’ll have to refactor the office export.

+1 to deprecate and extract the old PDF code from oldcore in 16.x

Thanks,
Marius

#8

Hi Marius,

Do you realize that this means supporting the old PDF export in 15.10+, and thus fixing the following 30 issues ideally: Loading...

This is why I was proposing to deprecate it and mark it unsupported now (but possibly move it only in 16.0 to reduce risks although I don’t think it’s a real issue). This is also why I sent the list of jira issues we fixed for it in the past year, to show that in practice it’s currently not supported. So we coud indeed cheat and say it’s supported and not support it, but not sure it helps much.

Also, I don’t think we’re doing anyone a favor by keeping open jira issues that we know we’re not going to fix. Hence my comment above:

So to recap, what I’m proposing is to mark it deprecated officially + minimally supported (ie only blocker bugs) and close all jira issues we’re not going to fix.

WDYT?

#9

Indeed, I didn’t think about this.

OK. So the end user will know it’s deprecated:

  • by reading the release notes
  • by noticing the deprecation warning messages logged when using the old PDF export

Right?

#10

Do we have that already? I don’t think we should show this since admins may want their users to use the old PDF export for some reason.

Yes, and also in the doc for the old PDF export:

WDYT?

Thanks

#11

So you want to deprecate it only at documentation level. What about the configuration that enables the old PDF export export.pdf.replaceFOP which is exposed in the PDF Export administration section? On a new installation the administrator may enable it without being aware it’s deprecated (without reading the documentation).

#12

Not only. This is what I’m proposing:

#13

Personally I would remove it from the UI (I don’t think we should have added it TBH) and only keep it at the xwiki.properties level, with a comment explaining it’s temporary and will be removed and mention there that the old PDF export is deprecated and not supported anymore.

WDYT?

#14

Fine with me. I created Loading... .

Thanks,
Marius