Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nosql-dev] This PR is one proposal option about the TCKskeletonin the Jakarta NoSQL project.

It’s not really cleaner because the specs all divert and cannot even be called from a single place. Nor are there compatibility requirements.

The majority used TestNG like CDI and other JSRs inspired (such as 385 ;-)

There are a lot of optional tests and no guidance or definitnion what happens if e.g. your optional tests may fail but the base tests all pass or vice versa. It does not have a strong profile definition.

 

Is the skeleton based on TestNG?

 

At the moment that is common to both Microprofile and Jakarta TCKs.

 

Also a main reason is, that MicroProfile unlike Jakarta EE has no dedicated space, so having a microprofile-config-api, microprofile-config-spec and microprofile-config-tck repo under the Eclipse organization plus 20 or  more others for the different MP specs may easily get totally confusing. That is different for the ee4j organization with a cleaner structure for Jakarta EE.

Microprofile is improvising a lot until it may get a new home (either at EE4J or elsewhere)

 

From: Otavio Santana
Sent: Tuesday, February 4, 2020 13:17
To: nosql developer discussions
Subject: Re: [nosql-dev] This PR is one proposal option about the TCKskeletonin the Jakarta NoSQL project.

 

Yeap, I know there are differences in the process.
But I feel that they started from the Java EE perspective and then make it both more modern and cleaner.

 

On Mon, Feb 3, 2020 at 6:27 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Hello,

 

I think we should take a similar discussion in the platform https://www.eclipse.org/lists/jakartaee-platform-dev/msg01477.html into consideration rather than acting independently.

 

MicroProfile is not a Jakarta Standard as of now, so the compatibility requirements are not alway as strict. There are pros and cons of either a separate TCK as oposed to having a single repository for Spec, API and TCK. Errata only found in either of those would be a Problem if they are physically together, because then Tagging only the TCK is Pretty much impossible, so you alway have to release all of them even if just one changes.

 

Therefore let’s observe the platform discussion and see, what other Projects think About it.

 

Werner

 

Sent from Mail for Windows 10

 

From: Otavio Santana
Sent: Monday, February 3, 2020 01:42
To: jnosql developer discussions; nosql developer discussions; Wayne Beaton; Ivar Grimstad
Subject: [nosql-dev] This PR is one proposal option about the TCK skeletonin the Jakarta NoSQL project.

 

Hello everyone.
I guess that is our first email in the year, so happy new year.

I want to start this year with the TCK discussion. Who has not idea what TCK is, briefly, TCK is the Technology Compatibility Kit (TCK) is a suite of tests that at least nominally checks a particular alleged implementation.

I’ve checked some TCKs, and I found two different structures:

  1. The first one is the TCK outside and with its repository.
    Examples:
  1. A TCK close to the API and the specification, it is the standard way that Eclipse Micprofile does:

I like the second option, for some reasons:

  • TCK close to the API
  • One repository less
  • Lesse repository might mean less complexity
  • It will be easier to change the API and TCK in the same PR.
  • Easier to CI

I created a PR:

Please, feel free to give any feedback about it.

 

 

--

Otávio Santana

 

 

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


 

--

Otávio Santana

 

 

Back to the top