Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 > sling-org-apache-sling-contentparser-xml > sling-org-apache-sling-contentparser-xml-jcr
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 same time I partially understand Stefan’s concerns, and given that it’s just a number I’m fine with releasing o.a.s.contentparser.api with version 2.0.0. I will create the following repositories in the meantime: sling-org-apache-sling-contentparser-api sling-org-apache-sling-contentparser-json sling-org-apache-sling-contentparser-xml sling-org-apache-sling-contentparser-xml-jcr Thanks, Radu
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 old API will need to be deprecated for the new one. And semantically the new one should be 1.0.0 -- Jason On Fri, Jul 19, 2019, at 11:51 AM, Radu Cotescu wrote: > 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 > > but a different API, this gets very puzzling. > > > > stefan > > > > Ok, then let’s start everything here with version 2.0.0 - all bundle > versions, all exported packages. > > Cheers, > Radu
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 > but a different API, this gets very puzzling. > > stefan > Ok, then let’s start everything here with version 2.0.0 - all bundle versions, all exported packages. Cheers, Radu
RE: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 but a different API, this gets very puzzling. stefan >-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 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 sense? We anyways >changed the package name so consumers of the new API will have to perform a >minor refactoring when migrating from the previous one. > >Thanks, >Radu
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 sense? We anyways changed the package name so consumers of the new API will have to perform a minor refactoring when migrating from the previous one. Thanks, Radu
RE: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+1 with the latest changes from https://github.com/apache/sling-whiteboard/pull/47 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. stefan >-Original Message- >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 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
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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.
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 that > end, I think the ParserOptions should not be a final class but encompass the > generic options available to all content parsers and then have extended > classes in the other packages that reflect the ParserOptions for that package. > > So there'd be a JsonParserOptions which extends ParserOptions and contains > json specific options. > > So for me to implement a YamlContentParser I should just be able to implement > the appropriate classes and install an implementation package. > > That would also mean moving implementation specific files to their respective > packages as well, like the JsonParserFeatures > > -- > Jason > Duly noted. I’ll try to implement these changes tomorrow. Cheers, Radu
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 encompass the generic options available to all content parsers and then have extended classes in the other packages that reflect the ParserOptions for that package. So there'd be a JsonParserOptions which extends ParserOptions and contains json specific options. So for me to implement a YamlContentParser I should just be able to implement the appropriate classes and install an implementation package. That would also mean moving implementation specific files to their respective packages as well, like the JsonParserFeatures -- Jason On Wed, Jul 17, 2019, at 4:02 AM, Radu Cotescu wrote: > 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. > >
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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.
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 [0]. Let me know if you have any > objections or feedback that I should incorporate before moving the > modules to their own git repositories. Could you add a short description of what changed, what was added, what was removed (if anything was removed)? Thanks! Robert
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 incorporate before moving the modules to their own git repositories. Thanks, Radu [0] - https://github.com/apache/sling-whiteboard/tree/master/contentparser/
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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.
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+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 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 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 > > > > > > >
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+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 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 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 > > > >
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+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 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 > >
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
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 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
[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 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
