Breaking the feed API in order to remove ROME 1

Development
1

Hi everyone,

unfortunately, to get rid of ROME 1, we need to break the API of the feed API, mainly the feed plugin but also quite some related classes as they all expose classes of ROME 1 that either don’t exist in ROME 2 or have another package. While the Jira issue suggests moving the feed plugin to a legacy module or a contrib extension, I think the better solution is actually to just slightly break backwards compatibility by replacing the exposed classes by their ROME 2 equivalents.

This has the advantage that we can get truly rid of the (unmaintained, insecure) dependencies while keeping the full functionality. In a second step, we could then design a new feed script service and actually move the feed plugin to legacy. I believe the breakage is okay as the new version has classes that have mostly the same API. There seem to be differences, for example SyndEntry#setContributors now expects a list of SyndPerson instead of a list of strings, but this was the only thing I needed to adapt in the Java code. I ran some integration tests that render feeds and also tested the blog extension manually, and it still seems to work, the feeds are still available.

You can find the changes that I suggest at XWIKI-15705: Move to com.rometools version of the Rome API by michitux · Pull Request #3576 · xwiki/xwiki-platform · GitHub

I’m opening this vote to accept the breaking changes in our public API. Here is my +1.

I’ll leave this vote open for 72 hours until Sunday, October 20, 2024, included.

Thank you very much!

2

+1, but I feel it would be better to wait for 17.0.0 to push this breakage

3

+1 for 17.x as well.

4

Same on my side.

Thanks,
Marius

5

It’s a big breakage (not a small one) since it means any extension or custom code using the Feed plugin will fail to execute in the version of XWiki having that breakage.

In the jira issue I had listed some known extensions using it:

  • Forum app
  • Blog app
  • XWiki Reader (deprecated)

This means we’ll need to quickly provide new releases of the Forum + Blog apps to make them work, as part of this change.

It would also be interesting to contact some sponsoring companies to ask them to comment on this VOTE, in case it’s a big problem for them (I’ll contact XWiki SAS).

+1 for 17.0.0

<offtopic>
PS: There’s also the future question of what RSS API to use in the future. I remember we started a quick discussion about this when I started to use the rssreader library for the “What’s New” feature

    <dependency>
      <groupId>com.apptasticsoftware</groupId>
      <artifactId>rssreader</artifactId>
      <version>3.8.2</version>
    </dependency>

See GitHub - w3stling/rssreader: A simple Java library for reading RSS and Atom feeds

I think rssreader only reads RSS feeds but doesn’t generate them, to be checked. Rome does both. OTOH the rssreader API seems much more modern.

Anyway, I don’t think we need to conclude here, just wanted to raise it as it’s a bit related.
</offtopic>

6

I forgot the most important: thank you @MichaelHamann for tackling this! :slight_smile:

7

No, as I mentioned, I tested the (unchanged) blog extension, and it still works after my breaking changes. This is because I haven’t found any Java code that uses the feed plugin - and the Velocity scripts don’t care that the package of the classes changed as long as their APIs are the same for the parts they actually use.

I intentionally didn’t do any bigger changes even though they would totally be warranted in order to not break extensions like the blog extension.

1 Like
8

Indeed, I had forgotten this part (Velocity). Nice.

Thanks

9

I just took a look at the XWiki Reader app and I don’t see how those changes would break it. It’s only using very basic public APIs and they should still work.

10

And it doesn’t matter as it’s very old and dead. Needs to be moved to the attic probably.

EDIT: I’m actually surprised that @ppantiru made a change 6 years ago :wink: Before that it hadn’t been touched for 8 more years.

11

I’m closing this vote with 4 committers replying, all +1 to apply this for XWiki 17.0.0. I’ve updated the fix version of the issue accordingly and I’ll apply the change after the release of XWiki 16.10.0.