+1 for this idea -- Jason
On Thu, Jul 4, 2019, at 11:55 AM, Radu Cotescu wrote: > 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 > >
