+1 I like your idea! I vaguely remember having similar thoughts in the past, but considered it too much effort for what I was after at the time.
Regards Julian On Fri, Jul 5, 2019 at 3:41 PM Jason E Bailey <[email protected]> wrote: > > +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 > > > >
