I think some kind of in-container JUnit runner would be ideal, so specification projects could continue writing plain JUnit tests and not have to complicate them for the benefit of the platform & profiles.
I wasn't aware Jakarta Batch had something like that already. Sounds worth exploring. My experience with Arquillian is that you do need to code your tests explicitly to be Arquillian tests and I can understand why some specifications would not want that complication. I'd be interested even for my own personal usage if there was a way to use it that didn't involve Arquillian annotations and ShrinkWrap in the test code and was true and pure JUnit.
Such a runner would ideally be maintained in a central place and not have to be the responsibility of each individual spec project to duplicate/maintain. Here seems the most ideal location.
-David
On Apr 14, 2022, at 9:25 AM, Kyle Aure <kylejaure@xxxxxxxxx> wrote:
Hello All,
Just wanted to give my two cents on this topic.
It seems like the JSON-B and JSON-P TCKs were re-written to just be test repositories with the philosophy of "run these tests wherever you like"
In previous discussions, the development team of the JSON-B TCK pointed me to the JBatch TCK (and other resources) which does something similar but provides a "runner" to take their plain old Junit tests, package them, and deploy them to a platform server for testing (using Arquillian).
I think it would be nice if we had a separate project to develop a "runner" so standalone TCKs that want to just write tests don't have to worry about the deployment piece.
This would also offer consistency between our standalone TCKs.
For example, for the Concurrency TCK, I basically had to write my own testframework which is different than both JSON-B and JBatch.
Again just an idea,
Kyle Jon Aure
On Wed, Apr 13, 2022 at 11:28 PM Gurunandan Rao <gurunandan.rao@xxxxxxxxxx> wrote:
IMO, practical solution would be to enhance migrated/separated JSONB/JSONP TCK run in SE/Container(or SE/profile) mode, we should not add the removed JSON-B/JSON-P tests back in Platform TCK.
Also, We can have maintenance release of JSONB/JSONP TCK(post Jakarta EE 10 release), for support of SE/profile mode and need not wait for new Jakarta EE release to enhance TCK(if maintenance release of TCK with container enhancement is permitted as per Jakarta EE process).
regards,
Guru
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of David Blevins <dblevins@xxxxxxxxxxxxx>
Sent: 13 April 2022 22:56
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Subject: [External] : Re: [jakartaee-platform-dev] [jakartaee-tck-dev] : Re: Discussion of enabling JSON-B, JSON-P TCKs to be executed in EE Container (same as previous releases)
> On Apr 13, 2022, at 7:00 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>
>
> On 4/13/22 8:51 AM, Thomas Watson wrote:
>> 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.
I agree with all the very pragmatic statements you made in your email. Specifically about resourcing, being at limits, needing volunteers and the impact TCKs have on a specification project's ability to thrive. Extremely critical stuff.
I do want to flag up that if a Platform/Profile includes a specification, it is that Platform/Profile's responsibility to define the testing requirements they think are necessary. So while I agree having discussion happen in individual specification projects, we should continue the broader conversation here.
Regardless of what individual specification projects decide, we're still on the hook for the TCK requirements we define. If an individual specification decides they are an SE-focused spec that can run outside a container and create a TCK for that, that's great. When we create the requirement that it can work inside a Platform/Profile, we're on the hook for deciding and delivering on those testing requirements.
In practical terms, this may mean that if some specification projects are producing and shipping junit tests (for example), and we decide we want those tests to be runnable in a container, we create our own in-container JUnit runner similar to how IDE's have their own JUnit runner and Maven and Gradle have their JUnit runner.
But again, we first decide our goals. Then we look at the resources. Then we have some pragmatic discussions on what we can achieve.
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dxjKN5ceunw25v9xzw7TA6migCQnufuhcSGCfhdB_xx8hgiu6idMP0Wp07BtvqYPEJg$
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
