I think the downside of all of these solutions is that they all require
service loader support - which drags in a lot of other stuff.
We should try to convince the johnzon community to remove the hard
requirement on serviceloader - it doesn't really make sense in this
case. and then we would have an apache, dependency free implementation.
To avoid all those dependencies I switched to
"org.glassfish:jakarta.json:2.0.1" for my projects. Its older, but works
and does not require service loader or anything else at all.
Regards
Carsten
On 17.11.2023 20:37, Eric Norman wrote:
Is the johnzon 2.x implementation better than the parsson library that we
are already including in the starter?
I've just been switching the geronimo-json_1.0_spec and johnzon-core
dependencies to these:
<!-- for the jakarta.json APIs -->
<dependency>
<groupId>jakarta.json</groupId>
<artifactId>jakarta.json-api</artifactId>
<version>2.1.1</version>
<scope>provided</scope>
</dependency>
<!-- for the jakarta.json implementation used by tests -->
<dependency>
<groupId>org.eclipse.parsson</groupId>
<artifactId>parsson</artifactId>
<version>1.1.1</version>
<scope>test</scope>
</dependency>
Regards,
-Eric
On Fri, Nov 17, 2023 at 3:03 AM Stefan Seifert
<[email protected]> wrote:
in context of SLING-12058 we are migrating lots of modules from javax.json
to jakarta.json. this works fine for modules using javax.json directly.
however, we have a few modules which are using johnzon, which uses
javax.json internally. since version johnzon 1.2.5 (we are using johnzon
1.2.21 in latest wrapper bundle) johnzon ships an additional artifact with
classifier "jakarta", which uses jakarta.json internally. both artifacts
with and without "jakarta" are identical, except the internal usage of the
package name. our wrapper bundle contains the version using javax.json.
for non-bundles like maven plugins we can just switch to the artifact with
"jakarta". but this will not work for our bundles. we cannot ship both
artifacts with and without "jakarta" classifier as wrapper bundles and
export them both in OSGi with the same version number. i've found at least
one bundle where this is already used (but not released) [1]. it stumbled
about this in PR [2]. the bundles might work anyway as the bundle compiled
against the johnzon "jakarta" affect should also work with the javax.json
version at runtime, but this feels like a slippery slope.
according to [3] johnzon is using a different way starting from version
2.0 (which seems to be released a few days ago, although the homepage is
not updated yet): in version 2.0 johnzon uses only jakarta.json.
so it think the correct way is to create and deploy an additional wrapper
bundle for johnzon 2.0, which we can deploy side-by-side with the old
wrapper bundle with 1.x. i assume we have to support both of them for quite
a time, as there is a lot of code out there using johnzon 1.x.
WDYT?
stefan
[1]
https://github.com/apache/sling-org-apache-sling-installer-factory-feature/blob/867bd44f0991cedd130314d833c9aac29ae3f36c/pom.xml#L134-L140
[2] https://github.com/apache/sling-org-apache-sling-fsresource/pull/2
[3] https://johnzon.apache.org/download.html
--
Carsten Ziegeler
Adobe
[email protected]
