Integrate TCK test execution in jsonb/core modules

[jungm]

IMO TCK tests should be considered part of our normal test suite and not be hidden behind a profile, IIRC they were only moved to a seperate profile to not break the build when the EE10 TCK branch got merged

[rmannibucau]

Do we want to make it lazy and enable tck module or make it right and run it as part of the modules they test instead (and drop tck module) now?

[jungm]

+1 for dropping TCK modules and integrating it right into the implementing modules

IIRC at least the json-p pluggability tests were quite flimsy to set up, I'll try to make it work

[jungm]

I believe we actually have no need to run pluggability tests. They test the JSON-P SPI which isn't even part of johnzon: https://github.com/jakartaee/jsonp-api/blob/2.1.1-tck/tck/tck-tests-pluggability/src/main/java/ee/jakarta/tck/jsonp/pluggability/jsonprovidertests/ClientTests.java

[rmannibucau]

@jungm depends, if you want to be certified you need to since the certification is for the impl+used api to pass it (see it as "standalone" bundle). No strong opinion on it.

[jungm]

I guess if we ever want to be certified we would need to use the test harness provided with the TCK anyways (https://github.com/jakartaee/jsonp-api/tree/master/tck/tck-dist-eftl, https://github.com/jakartaee/jsonb-api/tree/master/tck-dist), though not sure to be fair

Anyways, I see no real advantage of running pluggability tests if we don't have a jsonp-api module

[rmannibucau]

Hmm I'm not sure of this part.

Anyways, I see no real advantage of running pluggability tests if we don't have a jsonp-api module

We decided to inherit from the official one so we do have it, the point of these tests is to ensure you don't break the API impl on that part - this is more obvious for containers which could hardcode the SPI or prevent the pluggability - it is often togglable like in TomEE.
But long story short we should run it even if we fake the env for these tests to show our impl does not prevent it and does not break it, nothing more IMHO.

[jungm]

Spent some time on this now, running pluggability tests within johnzon-core is doable but the solution I came up with feels like a terrible hack IMO

There's also still a weird issue with the javadoc plugin still happening right now (mvn clean install -Dmaven.javadoc.skip works fine already)

[rmannibucau]

Javadoc should run anyway so not a big deal pby.
Not sure about the hack, is it using vintage engine?

[jungm]

Yeah running vintage engine could probably clean up things a bit more, didn't think of this and went straight to configuring providers when I saw surefire automatically switching to jupiter provider once I dropped in the tck dependencies

The actual hack I meant though is this:

johnzon/johnzon-core/pom.xml

Line 161 in 9050a4d

<classesDirectory>${project.build.outputDirectory}/nowhere</classesDirectory>

[rmannibucau]

This hack is ok for me

[jungm]

Build works now, it was failing due to sigtest-maven-plugin having a dependency on the local file ${java.home}/lib/ct.sym, see jtulach/netbeans-apitest#3
Having this dependency breaks javadoc plugin though, I excluded the dependency for now and it does not break tests. Probably worth investigating more and raising issues where appropriate

Johnzon tests also run on junit 5 now (through vintage engine for now)