+1 Le ven. 5 juil. 2019 à 19:49, Julian Sedding <[email protected]> a écrit :
> +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 > > > > > > >
