Rome 2 Questionnaire

Hi everyone!

If you’re interested in the future of Rome, please fill out (and share) this google from. If you don’t have a google account, or don’t like forms, feel free to write your thoughts in the comment section below.

The text below is a copy-paste from the form.

I would like to initiate development of Rome 2.

With recent announcements of JSON Feed and new Itunes RSS tags Rome starts lagging behind. While some modifications are relatively easy to implement, other are not at all. On top of that the Rome codebase is ancient and does not particularly boost productivity.

This is why I would like to suggest a complete rewrite. There is nothing advanced in what the current code does. I believe it can be easily replicated, improved and extended.

Here is a random list of things I would like to see in the new version:

• Java 8
• Better API (something like Rome.minimal().readUrl("..."), see more in this gist)
• Android support (as in we know it works, not just assume)
• Drop support for old standards (e.g. RSS 1.0)
• Get rid of rome.properties
• Expose raw strings for fields like date (in addition to the parsed value)
• Similarly expose parsing errors (also never fail completely because of invalid fields)
• Expose the old SyndFeed object (to ease transition)
• Single artifact (merge core rome and rome-modules)
• Single maven dependency: slf4j-api
• Code generation (stop writing getters and setters by hand)
• Immutability and builders

If you agree, disagree or have other ideas or concerns, please fill out the form or leave a comment.

@PatrickGotthard and @imk already questioned some of my ideas. To reach an agreement I’m going to hold a public discussion (in form of github issues) on each controversial topic.

Tagging everyone who has been active in Rome development: @snoopdave @icyerasor @Athou @buckett @IgnacioDomingo @mityi @Joerg-Schoemer @farrukhnajmi @michael-simons @dipacs @markhobson @fschiettecatte @eknoes @mDandini @rchakra3 @puntogil @matwood @sagen @AymanDF @freemarmoset @arankin @janih @tacoo

And reporters of recent issues: @jimsteel @GabrielBB @herau @buko @djvergel @johnedo1234 @dotquam @joaoBeno @Huangbin1234 @adelinolobao @bdurepo1 @endorphins @maxfieb @jannesep

[FrVaBe]

@michael-simons Have a look at #152 for the reasons why lombock was removed in the camunda-spring-boot-starter project.

[michael-simons]

@imk Yes, that’s my impression, too. As it isn’t too hard to generate accessors, its not the most convening use case. Constructors might be. But TBH I think that it’s better to keep it out.