sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Peltier <npelt...@apache.org>
Subject Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
Date Mon, 08 Jul 2019 07:39:38 GMT
+1

Le ven. 5 juil. 2019 à 19:49, Julian Sedding <jsedding@gmail.com> 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 <jason.bailey@24601.org>
> 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 <radu@apache.org> 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
> > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message