And also sling-org-apache-sling-contentparser-testutils.
> On 22 Jul 2019, at 09:45, Radu Cotescu wrote:
>
> I will create the following repositories in the meantime:
>
> sling-org-apache-sling-contentparser-api
> sling-org-apache-sling-contentparser-json
>
Hi Jason,
> On 19 Jul 2019, at 23:05, Jason E Bailey wrote:
>
> My opinion is that the old API will need to be deprecated for the new one.
> And semantically the new one should be 1.0.0
We will definitely deprecate the old API and reference the new one in the
module’s README file. At the
Okay, I'm going to counter this argument. The new content parser is a different
bundle, a different import, then the old content parser.
the old content parser package is
org.apache.sling.jcr.contentparser
That can and will co-exist with
org.apache.sling.contentparser
My opinion is that the
Hi Stefan,
> On 19 Jul 2019, at 15:20, Stefan Seifert wrote:
>
> i think the bundle users will not be really aware oft the removal of the tiny
> "jcr" part in the package name, for them it's only "the content parser".
> and if the new version after 1.2.6 is 1.0.0 has the same features as 1.2.6
efan
>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Friday, July 19, 2019 3:17 PM
>To: Sling Dev
>Subject: Re: [org.apache.sling.jcr.contentparser] can we decouple it from
>JCR?
>
>Hi Stefan,
>
>> On 19 Jul 2019, at 12:36, Stefan S
Hi Stefan,
> On 19 Jul 2019, at 12:36, Stefan Seifert wrote:
>
> in my pov the new modules should get version 2.0.0 as start version, as they
> are a successor of the old content parser with the same features, just
> bundled in a new way.
I know it’s just a number, but does it really make
age-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Thursday, July 4, 2019 5:00 PM
>To: Sling Dev
>Cc: Stefan Seifert
>Subject: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
>
>Hi Stefan,
>
>I do know that the module has JCR in its name, but do you thi
https://github.com/apache/sling-whiteboard/pull/47
> On 17 Jul 2019, at 20:10, Radu Cotescu wrote:
>
> Duly noted. I’ll try to implement these changes tomorrow.
Hi Jason,
> On 17 Jul 2019, at 15:16, Jason E Bailey wrote:
>
> My opinion - I'd prefer a greater decoupling of the API and implementations.
> We should be able to design this in such a way that the addition of a new
> format for parsing content doesn't necessitate a release of the API. To
My opinion - I'd prefer a greater decoupling of the API and implementations. We
should be able to design this in such a way that the addition of a new format
for parsing content doesn't necessitate a release of the API. To that end, I
think the ParserOptions should not be a final class but
https://github.com/apache/sling-whiteboard/tree/master/contentparser/org-apache-sling-contentparser-api
> On 16 Jul 2019, at 16:41, Radu Cotescu wrote:
>
> Sure, I’ll prepare a README.md file for each module.
Hi Robert,
> On 16 Jul 2019, at 13:13, Robert Munteanu wrote:
>
> Could you add a short description of what changed, what was added, what
> was removed (if anything was removed)?
Sure, I’ll prepare a README.md file for each module.
Thanks,
Radu
Hi Radu,
On Mon, 2019-07-15 at 13:56 +0200, Radu Cotescu wrote:
> Hi,
>
> > On 8 Jul 2019, at 22:20, Radu Cotescu wrote:
> >
> > Thanks for the +1s. I’ll start working in the whiteboard and hope
> > to have everything ready for review by the end of the week.
>
> The code is now available at
Hi,
> On 8 Jul 2019, at 22:20, Radu Cotescu wrote:
>
> Thanks for the +1s. I’ll start working in the whiteboard and hope to have
> everything ready for review by the end of the week.
The code is now available at [0]. Let me know if you have any objections or
feedback that I should
Thanks for the +1s. I’ll start working in the whiteboard and hope to have
everything ready for review by the end of the week.
+1
Le ven. 5 juil. 2019 à 19:49, Julian Sedding 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
> wrote:
> >
+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 wrote:
>
> +1 for this idea
>
> --
> Jason
>
> On Thu, Jul 4, 2019, at 11:55 AM, Radu
+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
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
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
20 matches
Mail list logo
