| Re: [jakartaee-tck-dev] [jakartaee-platform-dev] : Re: Discussion of enabling JSON-B, JSON-P TCKs to be executed in EE Container (same as previous releases) |
I agree with David on both points. We should be pragmatic to get the EE 10 released and work towards solving the TCK problem in a future specification release. The most important thing is to agree what the requirements are for running the individual TCKs within the platform/profile for which the specifications are included. Then we can work towards solving the requirements.
The TCK process currently states:
"
Challenges can be resolved by a specification project lead, or a
project challenge triage team, after a consensus of the
specification project committers is reached or attempts to gain
consensus fails. Specification projects may exercise lazy
consensus, voting or any practice that follows the principles of
Eclipse Foundation Development Process.
"
As per ^, the JSON-P/JSON-B SPEC team is responsible for the
JSON-P/JSON-B TCK tests, as the SPEC API team is responsible for
maintaining the TCK tests. In general, the current cost to many
SPEC API teams for maintaining the SPEC API projects is higher
than it would be with more contributors, at least that is my read
of what I heard during yesterdays Platform call, about the SPEC
API teams being at their limit of what they can contribute (e.g.
many SPEC API teams do not have the bandwidth to maintain any
duplicate TCK tests).
In my opinion, we should discuss on the JSON-B mailing list whether the Platform TCK could extend the new Standalone JSON-B TCK via thread [1]. If that discussion goes well, the next step should be creating a Platform TCK issue to track the work and then a volunteer can create a Platform TCK pull request to be merged after EE 10. Just to repeat why this needs to be discussed on [1], the reason (IMO) is because the JSON-B API team needs to do the later work of dealing with (time consuming) Platform TCK challenges.
I didn't ask on [1] but if anyone that is interested in helping
the JSON-B SPEC team to maintain their TCK tests running directly
on EE containers and the JSON-B API team agrees with that approach
(for reasons mentioned before which are not currently Platform
requirements), that could be an alternative but also keep in mind
that there is a cost to either approach, regardless of whether the
tests are maintained.
Scott
[1] https://www.eclipse.org/lists/jsonb-dev/msg00099.html
Tom.
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of David Blevins <dblevins@xxxxxxxxxxxxx>
Sent: Wednesday, April 13, 2022 1:52 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [jakartaee-tck-dev] [External] : Re: Discussion of enabling JSON-B, JSON-P TCKs to be executed in EE Container (same as previous releases)I'll say explicitly for everyone's benefit. If there are pragmatic concession we have to make in the short-term to get releases out the door, we're ok with that as long as we all agree on the long-term goal and work to get there.
That goal is when we say "Foo spec is part of the Bar Profile" we can run all the TCK tests for Foo inside our profile implementation.
The most important thing is we agree on that. Then we can have some pragmatic conversations on how to get there. That might involve changing very little to nothing about our current plans and leaving all the work for the next releases.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Apr 12, 2022, at 11:36 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
>> On Apr 12, 2022, at 9:42 PM, Gurunandan Rao <gurunandan.rao@xxxxxxxxxx> wrote:
>>
>> JSONB platform testsuite currently has new pluggability tests, since pluggability tests needs to be validated in a container such that conflicts with META-INF/services files, classloaders are detected. Also JSONB CDI tests which are run on servlet vehicle are part of platform TCK test suite(we can use same for validation of NoClassDefFoundErrors from missing dependency jars in a platform), other than Pluggability and CDI tests for JSONB, rest of the test (which don't require a container and use standalone vehicle) should be validated using standalone TCK(in standalone mode[junit tests]).JSONP platform testsuite has pluggability
>
> I think you've missed this call out I explicitly mentioned:
>
> "When I say that, people should not read that to mean the features of a spec that integrate with other specs. I mean basic functionality of the component failing when run in a fully integrated container."
>
> So when you say "than Pluggability and CDI tests for JSONB, rest of the test should be validated using standalone TCK" I think you might have misunderstood the feedback.
>
> It is not about pluggability as defined by the specification. I'm referring to APIs internal to an implementation that can customize basic functionality of how that implementation works.
>
> Does this make sense?
>
>
> -David
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev