My opinion - I'd prefer a greater decoupling of the API and implementations. We should be able to design this in such a way that the addition of a new format for parsing content doesn't necessitate a release of the API. To that end, I think the ParserOptions should not be a final class but encompass the generic options available to all content parsers and then have extended classes in the other packages that reflect the ParserOptions for that package.
So there'd be a JsonParserOptions which extends ParserOptions and contains json specific options. So for me to implement a YamlContentParser I should just be able to implement the appropriate classes and install an implementation package. That would also mean moving implementation specific files to their respective packages as well, like the JsonParserFeatures -- Jason On Wed, Jul 17, 2019, at 4:02 AM, Radu Cotescu wrote: > https://github.com/apache/sling-whiteboard/tree/master/contentparser/org-apache-sling-contentparser-api > > > On 16 Jul 2019, at 16:41, Radu Cotescu <[email protected]> wrote: > > > > Sure, I’ll prepare a README.md file for each module. > >
