Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec

Andy/all,

 

So does JSONB plan to do that in the same repository as the API?

And what About JSONP? With the latter I could also help if someone was to work on that.

 

I met Lukas from Oracle at JFokus yesterday, but he said he is not dedicating that much time and effort on it Right now.

 

Werner

 

Sent from Mail for Windows 10

 

From: Andy Guibert
Sent: Wednesday, February 5, 2020 19:55
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec

 

Ok, I have an MVP of what I have in mind, along with pending PRs on all of the corresponding repos.

 

1) I've ported the JSON-B TCK tests from JavaTest --> Arquillian+JUnit and included them in the JSON-B repo here:

2) Implementations can easily pull in the JSON-B TCK tests and run them. I've done this with Yasson here:

3) I've created a new aggregator module in the jakartaee-tck repo, which can be the single point where we pull in all of the externalized TCK tests. Each spec shares a small portion of pom.xml to pull in the TCK dependency, and then each vendor can implement a <profile> block to run the tests with their runtime. I've shown an example of this with BeanValidation and JSON-B using Liberty here:

 

As you can see, the externalized TCKs are quite flexible and can easily be consumed+run in other projects with other runtimes. I added the aggregator module (3) to the jakartaee-tck repo to try and preserve existing behavior as much as I could, but I still don't really see much value in it. IMO we should leave it up to the vendors to pull in the externalized TCKs in whatever repo works best for them. For example in IBM we have separate internal repos for consuming+running the CDI TCK tests and another for the BeanValidation TCK tests. If we were to add this aggregator module (3), the Liberty team wouldn't bother to use it.

 

Hopefully everyone is OK with how PR (1) looks, and the flexibility demonstrated in PR (2) with Yasson, or with what everyone is already doing for BeanValidation and CDI means we don't have to follow through with PR (3)?

 

On Tue, Feb 4, 2020 at 5:26 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

Emily Jiang wrote on 2/4/20 8:12 AM:
> I don't think the goal of breaking TCKs from the big bucket is to use a
> different test framework. I envisage the same test framework should be
> retained at least for the first release.
I agree, just as a way of reducing risk for the first release.

> I don't think using different test framework is something we should ban
> either. We should allow different specs to use a suitable test framework if
> there is strong benefit associated with the new test ramework.
I'd love to see a JUnit test runner that can run JavaTest tests, if that's even
possible.  That would allow us to move to a more commonly used test framework
while preserving the many, many, existing tests.  I suspect it's a lot harder
than I'm imaging, however...  :-(

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

Back to the top