You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2022/11/29 08:22:53 UTC
[RT] Migrating the feature model tooling to Jakarta JSON
Hi,
as you might know, starting with JEE 9 the package names changed from
javax.* to jakarta.* which means that we will benefit from updates to
those APIs only if we make the move.
This thread is *not* about moving the whole of Sling over, but just for
the feature model and the related tooling. This should be less painful
as usually this code is not used as OSGi bundles at runtime. If someone
wants to discuss how we should handle Sling itself (mostly the servlet
api), please start a new thread.
For the feature model and the tooling around it (including maven plugins
etc.) I suggest we simply replace javax.json with jakarta.json and do
new releases of everything involved with a new major version. As we are
currently using javax.json in parts of the API, this will be a breaking
change, therefore the major version update.
As we are talking about tooling here and as we can basically update all
the relevant tooling in one step, I think it is ok to go this way and we
can avoid thinking about a compatible migration path.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Dropping Java 8 support for the Sling Starter (was: [RT] Migrating the feature model tooling to Jakarta JSON)
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2023-04-21 at 11:44 +0200, Robert Munteanu wrote:
> I filed https://issues.apache.org/jira/browse/SLING-11840 to track
> this.
Follow-ed up with
https://github.com/apache/sling-org-apache-sling-starter/pull/152
Thanks,
Robert
Re: Dropping Java 8 support for the Sling Starter (was: [RT] Migrating the feature model tooling to Jakarta JSON)
Posted by Konrad Windszus <kw...@apache.org>.
I created some follow up tickets for that
https://issues.apache.org/jira/browse/SLING-11843
https://issues.apache.org/jira/browse/SLING-11842
https://issues.apache.org/jira/browse/SLING-11841
Please comment directly on those.
Thanks,
Konrad
> On 21. Apr 2023, at 12:02, Stefan Seifert <St...@diva-e.com.INVALID> wrote:
>
> makes sense, go ahead!
>
> we should consider dropping java 8 for new sling module releases in general, updating to java 11 in our sling-parent. java 8 is EOL for quite a long time, we can start using new language features, and drop java 8 builds in Jenkins.
>
> stefan
>
>> -----Original Message-----
>> From: Robert Munteanu <ro...@apache.org>
>> Sent: Friday, April 21, 2023 11:45 AM
>> To: dev@sling.apache.org
>> Subject: Dropping Java 8 support for the Sling Starter (was: [RT]
>> Migrating the feature model tooling to Jakarta JSON)
>>
>> Hi,
>>
>> Changing subject to make sure we get enough attention. With Oak 1.50
>> requiring Java 11 it does not look like we can hold on to Java 8 for much
>> longer.
>>
>> I filed https://issues.apache.org/jira/browse/SLING-11840 to track this.
>>
>> If anyone sees a reason to keep supporting Java 8, please say so.
>>
>> Note that this does not mean that the Sling bundles need to bump the
>> required version to Java 11, they can keep supporting Java 8 as long as it
>> is desired.
>>
>> Thanks,
>> Robert
>>
>> On Thu, 2023-04-20 at 10:37 -0700, Eric Norman wrote:
>>>>
>>>> 2. Officially drop support for Java 8 in the Starter (not
>>>> necessarily the bundles) and incorporate Parsson
>>>>
>>>
>>> I wouldn't have a problem with bumping the minimum java version for
>>> the
>>> starter to the minimum LTS OpenJDK version that is still receiving
>>> active
>>> support (currently version 11). It looks like active support for
>>> OpenJDK
>>> 8 ended over a year ago and it now receives only security related
>>> fixes.
>>>
>>> Also, Oak 1.50.0 now requires java 11 so we can't use the latest
>>> production
>>> release of oak with java 8.
>>>
>>> Regards,
>>> -Eric
>>>
>>> On Wed, Apr 19, 2023 at 1:21 PM Robert Munteanu <ro...@apache.org>
>>> wrote:
>>>
>>>> On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
>>>>> I added Parsson to the contentloader 2.6.0 PR
>>>>>
>>>>>
>>>>> https://github.com/apache/sling-org-apache-sling-starter/pull/105
>>>>>
>>>>> Seems to work fine locally. I will split this to a different PR,
>>>>> just
>>>>> wanted to push it out there for review.
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>
>>>> Parsson requires Java 9, but we still run tests on Java 8
>>>>
>>>> [ERROR] [requirements-capabilities]
>>>> org.eclipse.parsson:jakarta.json:1.1.1: Artifact
>>>> org.eclipse.parsson:jakarta.json:1.1.1 requires
>>>> [org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
>>>> filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
>>>> artifact is providing a matching capability in this start level.
>>>>
>>>> There are two ways out:
>>>>
>>>> 1. Look for another parser implementation
>>>> 2. Officially drop support for Java 8 in the Starter (not
>>>> necessarily
>>>> the bundles) and incorporate Parsson
>>>>
>>>> I slightly favour option 2, I think people deploying new versions
>>>> of
>>>> the Starter can choose a more recent version of the Java runtime.
>>>>
>>>> Thoughts?
>>>>
>>>> Robert
>>>>
>
Re: Dropping Java 8 support for the Sling Starter (was: [RT] Migrating the feature model tooling to Jakarta JSON)
Posted by Konrad Windszus <kw...@apache.org>.
There was a similar discussion already at https://lists.apache.org/thread/6p86tqpldjj83zw3288ooht869yt99dr and back then we already kind of reached consensus that it is time to require Java 11 also for bundles nowadays.
Konrad
> On 21. Apr 2023, at 12:02, Stefan Seifert <St...@diva-e.com.INVALID> wrote:
>
> makes sense, go ahead!
>
> we should consider dropping java 8 for new sling module releases in general, updating to java 11 in our sling-parent. java 8 is EOL for quite a long time, we can start using new language features, and drop java 8 builds in Jenkins.
>
> stefan
>
>> -----Original Message-----
>> From: Robert Munteanu <ro...@apache.org>
>> Sent: Friday, April 21, 2023 11:45 AM
>> To: dev@sling.apache.org
>> Subject: Dropping Java 8 support for the Sling Starter (was: [RT]
>> Migrating the feature model tooling to Jakarta JSON)
>>
>> Hi,
>>
>> Changing subject to make sure we get enough attention. With Oak 1.50
>> requiring Java 11 it does not look like we can hold on to Java 8 for much
>> longer.
>>
>> I filed https://issues.apache.org/jira/browse/SLING-11840 to track this.
>>
>> If anyone sees a reason to keep supporting Java 8, please say so.
>>
>> Note that this does not mean that the Sling bundles need to bump the
>> required version to Java 11, they can keep supporting Java 8 as long as it
>> is desired.
>>
>> Thanks,
>> Robert
>>
>> On Thu, 2023-04-20 at 10:37 -0700, Eric Norman wrote:
>>>>
>>>> 2. Officially drop support for Java 8 in the Starter (not
>>>> necessarily the bundles) and incorporate Parsson
>>>>
>>>
>>> I wouldn't have a problem with bumping the minimum java version for
>>> the
>>> starter to the minimum LTS OpenJDK version that is still receiving
>>> active
>>> support (currently version 11). It looks like active support for
>>> OpenJDK
>>> 8 ended over a year ago and it now receives only security related
>>> fixes.
>>>
>>> Also, Oak 1.50.0 now requires java 11 so we can't use the latest
>>> production
>>> release of oak with java 8.
>>>
>>> Regards,
>>> -Eric
>>>
>>> On Wed, Apr 19, 2023 at 1:21 PM Robert Munteanu <ro...@apache.org>
>>> wrote:
>>>
>>>> On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
>>>>> I added Parsson to the contentloader 2.6.0 PR
>>>>>
>>>>>
>>>>> https://github.com/apache/sling-org-apache-sling-starter/pull/105
>>>>>
>>>>> Seems to work fine locally. I will split this to a different PR,
>>>>> just
>>>>> wanted to push it out there for review.
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>
>>>> Parsson requires Java 9, but we still run tests on Java 8
>>>>
>>>> [ERROR] [requirements-capabilities]
>>>> org.eclipse.parsson:jakarta.json:1.1.1: Artifact
>>>> org.eclipse.parsson:jakarta.json:1.1.1 requires
>>>> [org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
>>>> filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
>>>> artifact is providing a matching capability in this start level.
>>>>
>>>> There are two ways out:
>>>>
>>>> 1. Look for another parser implementation
>>>> 2. Officially drop support for Java 8 in the Starter (not
>>>> necessarily
>>>> the bundles) and incorporate Parsson
>>>>
>>>> I slightly favour option 2, I think people deploying new versions
>>>> of
>>>> the Starter can choose a more recent version of the Java runtime.
>>>>
>>>> Thoughts?
>>>>
>>>> Robert
>>>>
>
RE: Dropping Java 8 support for the Sling Starter (was: [RT] Migrating the feature model tooling to Jakarta JSON)
Posted by Stefan Seifert <St...@diva-e.com.INVALID>.
makes sense, go ahead!
we should consider dropping java 8 for new sling module releases in general, updating to java 11 in our sling-parent. java 8 is EOL for quite a long time, we can start using new language features, and drop java 8 builds in Jenkins.
stefan
> -----Original Message-----
> From: Robert Munteanu <ro...@apache.org>
> Sent: Friday, April 21, 2023 11:45 AM
> To: dev@sling.apache.org
> Subject: Dropping Java 8 support for the Sling Starter (was: [RT]
> Migrating the feature model tooling to Jakarta JSON)
>
> Hi,
>
> Changing subject to make sure we get enough attention. With Oak 1.50
> requiring Java 11 it does not look like we can hold on to Java 8 for much
> longer.
>
> I filed https://issues.apache.org/jira/browse/SLING-11840 to track this.
>
> If anyone sees a reason to keep supporting Java 8, please say so.
>
> Note that this does not mean that the Sling bundles need to bump the
> required version to Java 11, they can keep supporting Java 8 as long as it
> is desired.
>
> Thanks,
> Robert
>
> On Thu, 2023-04-20 at 10:37 -0700, Eric Norman wrote:
> > >
> > > 2. Officially drop support for Java 8 in the Starter (not
> > > necessarily the bundles) and incorporate Parsson
> > >
> >
> > I wouldn't have a problem with bumping the minimum java version for
> > the
> > starter to the minimum LTS OpenJDK version that is still receiving
> > active
> > support (currently version 11). It looks like active support for
> > OpenJDK
> > 8 ended over a year ago and it now receives only security related
> > fixes.
> >
> > Also, Oak 1.50.0 now requires java 11 so we can't use the latest
> > production
> > release of oak with java 8.
> >
> > Regards,
> > -Eric
> >
> > On Wed, Apr 19, 2023 at 1:21 PM Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > > On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
> > > > I added Parsson to the contentloader 2.6.0 PR
> > > >
> > > >
> > > > https://github.com/apache/sling-org-apache-sling-starter/pull/105
> > > >
> > > > Seems to work fine locally. I will split this to a different PR,
> > > > just
> > > > wanted to push it out there for review.
> > > >
> > > > Thanks,
> > > > Robert
> > >
> > > Parsson requires Java 9, but we still run tests on Java 8
> > >
> > > [ERROR] [requirements-capabilities]
> > > org.eclipse.parsson:jakarta.json:1.1.1: Artifact
> > > org.eclipse.parsson:jakarta.json:1.1.1 requires
> > > [org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
> > > filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
> > > artifact is providing a matching capability in this start level.
> > >
> > > There are two ways out:
> > >
> > > 1. Look for another parser implementation
> > > 2. Officially drop support for Java 8 in the Starter (not
> > > necessarily
> > > the bundles) and incorporate Parsson
> > >
> > > I slightly favour option 2, I think people deploying new versions
> > > of
> > > the Starter can choose a more recent version of the Java runtime.
> > >
> > > Thoughts?
> > >
> > > Robert
> > >
Dropping Java 8 support for the Sling Starter (was: [RT] Migrating the feature model tooling to Jakarta JSON)
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
Changing subject to make sure we get enough attention. With Oak 1.50
requiring Java 11 it does not look like we can hold on to Java 8 for
much longer.
I filed https://issues.apache.org/jira/browse/SLING-11840 to track
this.
If anyone sees a reason to keep supporting Java 8, please say so.
Note that this does not mean that the Sling bundles need to bump the
required version to Java 11, they can keep supporting Java 8 as long as
it is desired.
Thanks,
Robert
On Thu, 2023-04-20 at 10:37 -0700, Eric Norman wrote:
> >
> > 2. Officially drop support for Java 8 in the Starter (not
> > necessarily
> > the bundles) and incorporate Parsson
> >
>
> I wouldn't have a problem with bumping the minimum java version for
> the
> starter to the minimum LTS OpenJDK version that is still receiving
> active
> support (currently version 11). It looks like active support for
> OpenJDK
> 8 ended over a year ago and it now receives only security related
> fixes.
>
> Also, Oak 1.50.0 now requires java 11 so we can't use the latest
> production
> release of oak with java 8.
>
> Regards,
> -Eric
>
> On Wed, Apr 19, 2023 at 1:21 PM Robert Munteanu <ro...@apache.org>
> wrote:
>
> > On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
> > > I added Parsson to the contentloader 2.6.0 PR
> > >
> > >
> > > https://github.com/apache/sling-org-apache-sling-starter/pull/105
> > >
> > > Seems to work fine locally. I will split this to a different PR,
> > > just
> > > wanted to push it out there for review.
> > >
> > > Thanks,
> > > Robert
> >
> > Parsson requires Java 9, but we still run tests on Java 8
> >
> > [ERROR] [requirements-capabilities]
> > org.eclipse.parsson:jakarta.json:1.1.1: Artifact
> > org.eclipse.parsson:jakarta.json:1.1.1 requires
> > [org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
> > filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
> > artifact is providing a matching capability in this start level.
> >
> > There are two ways out:
> >
> > 1. Look for another parser implementation
> > 2. Officially drop support for Java 8 in the Starter (not
> > necessarily
> > the bundles) and incorporate Parsson
> >
> > I slightly favour option 2, I think people deploying new versions
> > of
> > the Starter can choose a more recent version of the Java runtime.
> >
> > Thoughts?
> >
> > Robert
> >
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Eric Norman <en...@apache.org>.
>
> 2. Officially drop support for Java 8 in the Starter (not necessarily
> the bundles) and incorporate Parsson
>
I wouldn't have a problem with bumping the minimum java version for the
starter to the minimum LTS OpenJDK version that is still receiving active
support (currently version 11). It looks like active support for OpenJDK
8 ended over a year ago and it now receives only security related fixes.
Also, Oak 1.50.0 now requires java 11 so we can't use the latest production
release of oak with java 8.
Regards,
-Eric
On Wed, Apr 19, 2023 at 1:21 PM Robert Munteanu <ro...@apache.org> wrote:
> On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
> > I added Parsson to the contentloader 2.6.0 PR
> >
> > https://github.com/apache/sling-org-apache-sling-starter/pull/105
> >
> > Seems to work fine locally. I will split this to a different PR, just
> > wanted to push it out there for review.
> >
> > Thanks,
> > Robert
>
> Parsson requires Java 9, but we still run tests on Java 8
>
> [ERROR] [requirements-capabilities]
> org.eclipse.parsson:jakarta.json:1.1.1: Artifact
> org.eclipse.parsson:jakarta.json:1.1.1 requires
> [org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
> filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
> artifact is providing a matching capability in this start level.
>
> There are two ways out:
>
> 1. Look for another parser implementation
> 2. Officially drop support for Java 8 in the Starter (not necessarily
> the bundles) and incorporate Parsson
>
> I slightly favour option 2, I think people deploying new versions of
> the Starter can choose a more recent version of the Java runtime.
>
> Thoughts?
>
> Robert
>
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2023-04-19 at 16:54 +0200, Robert Munteanu wrote:
> I added Parsson to the contentloader 2.6.0 PR
>
> https://github.com/apache/sling-org-apache-sling-starter/pull/105
>
> Seems to work fine locally. I will split this to a different PR, just
> wanted to push it out there for review.
>
> Thanks,
> Robert
Parsson requires Java 9, but we still run tests on Java 8
[ERROR] [requirements-capabilities]
org.eclipse.parsson:jakarta.json:1.1.1: Artifact
org.eclipse.parsson:jakarta.json:1.1.1 requires
[org.eclipse.parsson.jakarta.json/1.1.1] osgi.ee;
filter:="(&(osgi.ee=JavaSE)(version=9))" in start level 1 but no
artifact is providing a matching capability in this start level.
There are two ways out:
1. Look for another parser implementation
2. Officially drop support for Java 8 in the Starter (not necessarily
the bundles) and incorporate Parsson
I slightly favour option 2, I think people deploying new versions of
the Starter can choose a more recent version of the Java runtime.
Thoughts?
Robert
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Robert Munteanu <ro...@apache.org>.
I added Parsson to the contentloader 2.6.0 PR
https://github.com/apache/sling-org-apache-sling-starter/pull/105
Seems to work fine locally. I will split this to a different PR, just
wanted to push it out there for review.
Thanks,
Robert
On Wed, 2023-04-19 at 16:24 +0200, Carsten Ziegeler wrote:
> Thanks Konrad, yes I think it was Eclipse Parsson which I used
>
> Regards
> Carsten
>
> On 19.04.2023 16:07, Konrad Windszus wrote:
> > To me it seems that Johnson isn’t really well maintained any longer
> > (see https://issues.apache.org/jira/browse/JOHNZON-389 and
> > https://issues.apache.org/jira/browse/JOHNZON-388) and isn’t
> > adopting new spec versions.
> > So we should definitely consider moving to
> > https://github.com/eclipse-ee4j/parsson which supports the latest
> > specs.
> > Haven’t tried it out myself, though.
> >
> > Konrad
> >
> > > On 19. Apr 2023, at 15:58, Carsten Ziegeler
> > > <cz...@apache.org> wrote:
> > >
> > > If we can go without maintaining our own wrapper, thats probably
> > > the better option.
> > >
> > > I think to remember that I ran into issues when using the
> > > glassfish implementation, but I can't really remember what it
> > > was. I ended up with using some Eclipse implementation which then
> > > worked fine.
> > > I know, the answer is not really that helpful. But at least there
> > > are different options out there.
> > >
> > > Regards
> > > Carsten
> > >
> > > On 19.04.2023 15:46, Robert Munteanu wrote:
> > > > On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
> > > > (snip)
> > > > > Which then opens the question which bundle we use at runtime
> > > > > for
> > > > > jakarta.json? OOTB the johnzon implementation is too heavy as
> > > > > it has
> > > > > too
> > > > > many dependencies. So we could do the same as for the javax
> > > > > version
> > > > > and
> > > > > provide a commons.johnzon.jakarta module?
> > > > Looks like the question is still open. Eric noted at [1] that
> > > > the pax-
> > > > exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if
> > > > that is a
> > > > good option for us.
> > > > IIUC we would have the following options
> > > > 1. The Glassfish implementation
> > > > 2. The Johnzon implementation
> > > > 3. Our own wrapper for Johnzon
> > > > As I wasn't involved in the Johnzon migration I don't have an
> > > > idea
> > > > about what it takes to create a similar module for the Jakarta
> > > > impl.
> > > > But maybe listing the options gets the ball rolling :-)
> > > > Thanks,
> > > > Robert
> > > > [1]:
> > > > https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
> > >
> > > --
> > > Carsten Ziegeler
> > > Adobe
> > > cziegeler@apache.org
> >
>
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks Konrad, yes I think it was Eclipse Parsson which I used
Regards
Carsten
On 19.04.2023 16:07, Konrad Windszus wrote:
> To me it seems that Johnson isn’t really well maintained any longer (see https://issues.apache.org/jira/browse/JOHNZON-389 and https://issues.apache.org/jira/browse/JOHNZON-388) and isn’t adopting new spec versions.
> So we should definitely consider moving to https://github.com/eclipse-ee4j/parsson which supports the latest specs.
> Haven’t tried it out myself, though.
>
> Konrad
>
>> On 19. Apr 2023, at 15:58, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> If we can go without maintaining our own wrapper, thats probably the better option.
>>
>> I think to remember that I ran into issues when using the glassfish implementation, but I can't really remember what it was. I ended up with using some Eclipse implementation which then worked fine.
>> I know, the answer is not really that helpful. But at least there are different options out there.
>>
>> Regards
>> Carsten
>>
>> On 19.04.2023 15:46, Robert Munteanu wrote:
>>> On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
>>> (snip)
>>>> Which then opens the question which bundle we use at runtime for
>>>> jakarta.json? OOTB the johnzon implementation is too heavy as it has
>>>> too
>>>> many dependencies. So we could do the same as for the javax version
>>>> and
>>>> provide a commons.johnzon.jakarta module?
>>> Looks like the question is still open. Eric noted at [1] that the pax-
>>> exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a
>>> good option for us.
>>> IIUC we would have the following options
>>> 1. The Glassfish implementation
>>> 2. The Johnzon implementation
>>> 3. Our own wrapper for Johnzon
>>> As I wasn't involved in the Johnzon migration I don't have an idea
>>> about what it takes to create a similar module for the Jakarta impl.
>>> But maybe listing the options gets the ball rolling :-)
>>> Thanks,
>>> Robert
>>> [1]:
>>> https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Konrad Windszus <ko...@gmx.de>.
At some point in the future we hopefully have https://openjdk.org/jeps/198 integrated in the JDK (but this is not even planned yet for JDK21)
> On 19. Apr 2023, at 16:07, Konrad Windszus <ko...@gmx.de> wrote:
>
> To me it seems that Johnson isn’t really well maintained any longer (see https://issues.apache.org/jira/browse/JOHNZON-389 and https://issues.apache.org/jira/browse/JOHNZON-388) and isn’t adopting new spec versions.
> So we should definitely consider moving to https://github.com/eclipse-ee4j/parsson which supports the latest specs.
> Haven’t tried it out myself, though.
>
> Konrad
>
>> On 19. Apr 2023, at 15:58, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> If we can go without maintaining our own wrapper, thats probably the better option.
>>
>> I think to remember that I ran into issues when using the glassfish implementation, but I can't really remember what it was. I ended up with using some Eclipse implementation which then worked fine.
>> I know, the answer is not really that helpful. But at least there are different options out there.
>>
>> Regards
>> Carsten
>>
>> On 19.04.2023 15:46, Robert Munteanu wrote:
>>> On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
>>> (snip)
>>>> Which then opens the question which bundle we use at runtime for
>>>> jakarta.json? OOTB the johnzon implementation is too heavy as it has
>>>> too
>>>> many dependencies. So we could do the same as for the javax version
>>>> and
>>>> provide a commons.johnzon.jakarta module?
>>> Looks like the question is still open. Eric noted at [1] that the pax-
>>> exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a
>>> good option for us.
>>> IIUC we would have the following options
>>> 1. The Glassfish implementation
>>> 2. The Johnzon implementation
>>> 3. Our own wrapper for Johnzon
>>> As I wasn't involved in the Johnzon migration I don't have an idea
>>> about what it takes to create a similar module for the Jakarta impl.
>>> But maybe listing the options gets the ball rolling :-)
>>> Thanks,
>>> Robert
>>> [1]:
>>> https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Konrad Windszus <ko...@gmx.de>.
To me it seems that Johnson isn’t really well maintained any longer (see https://issues.apache.org/jira/browse/JOHNZON-389 and https://issues.apache.org/jira/browse/JOHNZON-388) and isn’t adopting new spec versions.
So we should definitely consider moving to https://github.com/eclipse-ee4j/parsson which supports the latest specs.
Haven’t tried it out myself, though.
Konrad
> On 19. Apr 2023, at 15:58, Carsten Ziegeler <cz...@apache.org> wrote:
>
> If we can go without maintaining our own wrapper, thats probably the better option.
>
> I think to remember that I ran into issues when using the glassfish implementation, but I can't really remember what it was. I ended up with using some Eclipse implementation which then worked fine.
> I know, the answer is not really that helpful. But at least there are different options out there.
>
> Regards
> Carsten
>
> On 19.04.2023 15:46, Robert Munteanu wrote:
>> On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
>> (snip)
>>> Which then opens the question which bundle we use at runtime for
>>> jakarta.json? OOTB the johnzon implementation is too heavy as it has
>>> too
>>> many dependencies. So we could do the same as for the javax version
>>> and
>>> provide a commons.johnzon.jakarta module?
>> Looks like the question is still open. Eric noted at [1] that the pax-
>> exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a
>> good option for us.
>> IIUC we would have the following options
>> 1. The Glassfish implementation
>> 2. The Johnzon implementation
>> 3. Our own wrapper for Johnzon
>> As I wasn't involved in the Johnzon migration I don't have an idea
>> about what it takes to create a similar module for the Jakarta impl.
>> But maybe listing the options gets the ball rolling :-)
>> Thanks,
>> Robert
>> [1]:
>> https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Carsten Ziegeler <cz...@apache.org>.
If we can go without maintaining our own wrapper, thats probably the
better option.
I think to remember that I ran into issues when using the glassfish
implementation, but I can't really remember what it was. I ended up with
using some Eclipse implementation which then worked fine.
I know, the answer is not really that helpful. But at least there are
different options out there.
Regards
Carsten
On 19.04.2023 15:46, Robert Munteanu wrote:
> On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
>
> (snip)
>
>> Which then opens the question which bundle we use at runtime for
>> jakarta.json? OOTB the johnzon implementation is too heavy as it has
>> too
>> many dependencies. So we could do the same as for the javax version
>> and
>> provide a commons.johnzon.jakarta module?
>
> Looks like the question is still open. Eric noted at [1] that the pax-
> exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a
> good option for us.
>
> IIUC we would have the following options
>
> 1. The Glassfish implementation
> 2. The Johnzon implementation
> 3. Our own wrapper for Johnzon
>
> As I wasn't involved in the Johnzon migration I don't have an idea
> about what it takes to create a similar module for the Jakarta impl.
>
> But maybe listing the options gets the ball rolling :-)
>
> Thanks,
> Robert
>
> [1]:
> https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote:
(snip)
> Which then opens the question which bundle we use at runtime for
> jakarta.json? OOTB the johnzon implementation is too heavy as it has
> too
> many dependencies. So we could do the same as for the javax version
> and
> provide a commons.johnzon.jakarta module?
Looks like the question is still open. Eric noted at [1] that the pax-
exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a
good option for us.
IIUC we would have the following options
1. The Glassfish implementation
2. The Johnzon implementation
3. Our own wrapper for Johnzon
As I wasn't involved in the Johnzon migration I don't have an idea
about what it takes to create a similar module for the Jakarta impl.
But maybe listing the options gets the ball rolling :-)
Thanks,
Robert
[1]:
https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 29.11.2022 um 16:16 schrieb Robert Munteanu:
> ...
>
> Overall sounds good to me. The only problematic area that I see is the
> cpconverter, as that ends up embedded in various tools. Since it's a
> one-off, I hope it will not be problematic.
>
Yes, that was my hope, too. I finished updating the relevant tooling and
its slightly more complicated. The cpconverter uses the JCR
contentloader which in turn uses javax.json. That by itself is not a
issue, however, the way the Apache johnzon library is implemented you
can't run the javax and the jakarta version side by side. I tried to use
a different implementation, but that broke the JSON parsing. So
interestingly there seems to be a difference in the implementations...
Anyhow, sooner or later we have to update our bundles as well. With the
contentloader it is easy as this only affects the implementation not the
api, so I went ahead and updated that bundle as well.
Which then opens the question which bundle we use at runtime for
jakarta.json? OOTB the johnzon implementation is too heavy as it has too
many dependencies. So we could do the same as for the javax version and
provide a commons.johnzon.jakarta module?
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Migrating the feature model tooling to Jakarta JSON
Posted by Robert Munteanu <ro...@apache.org>.
Hi Carsten,
On Tue, 2022-11-29 at 09:22 +0100, Carsten Ziegeler wrote:
> Hi,
>
> as you might know, starting with JEE 9 the package names changed from
> javax.* to jakarta.* which means that we will benefit from updates to
> those APIs only if we make the move.
>
> This thread is *not* about moving the whole of Sling over, but just
> for
> the feature model and the related tooling. This should be less
> painful
> as usually this code is not used as OSGi bundles at runtime. If
> someone
> wants to discuss how we should handle Sling itself (mostly the
> servlet
> api), please start a new thread.
>
> For the feature model and the tooling around it (including maven
> plugins
> etc.) I suggest we simply replace javax.json with jakarta.json and do
> new releases of everything involved with a new major version. As we
> are
> currently using javax.json in parts of the API, this will be a
> breaking
> change, therefore the major version update.
>
> As we are talking about tooling here and as we can basically update
> all
> the relevant tooling in one step, I think it is ok to go this way and
> we
> can avoid thinking about a compatible migration path.
Overall sounds good to me. The only problematic area that I see is the
cpconverter, as that ends up embedded in various tools. Since it's a
one-off, I hope it will not be problematic.
Thanks,
Robert