Let me add more details. Three classes use JCR or JackRabbit dependencies: JcrXmlContentParser JcrXmlValueConverter XmlContentParser ParserHelper
What I’d suggest would be to separate the API from the implementation and then provide the parsers from different pluggable modules. In addition to that, I think that the ParserHelper could maybe be exposed in the API as a final class, much like the ContentParserFactory, and use a different Calendar parser instead of org.apache.jackrabbit.util.ISO8601. I could prepare a PR if you agree with the changes. Thanks, Radu > On 4 Jul 2019, at 17:00, Radu Cotescu <[email protected]> wrote: > > Hi Stefan, > > I do know that the module has JCR in its name, but do you think that we could > make the JCR stuff optional? I’d really like to reuse this module to parse > JSON into Sling resource trees, but I’d like the JCR dependencies to be > optional, since in my experimental setup I use a different resource provider. > > Thanks, > Radu
