Jakarta EE TCK, 8 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta EE Platform TCK Call #1 - September 8, 2021 7AM

Description

Recording of the Jakarta EE Platform TCK (Technology Compatibility Kit) call #1 on September 8, 2021, with full video.

Listen to the discussion about refactoring the Platform TCK for Jakarta EE. Minutes from the call are available at https://drive.google.com/file/d/11zzyIDqy94MGyVR90RsiVM6uufk9FsK9/view

A

If anyone has a problem being recorded, um you can hang up now, but otherwise we will get started and so far we have myself alwyn guru and we're going to jump right into the into the items on the agenda and um attendees are encouraged to help take notes as we go through okay.

A

So the first thing on the agenda is the platform tck refactoring. Can everyone hear me? Okay,.

B

A

Great, we can hear you, terrific, okay, so um um so yeah the um tck refactoring is the big um action um item that we're doing now and, as we've talked about on on the um mailing list, we you know we have the draft pull request, that um I've been pushing changes to and.

A

Here I think I want to mention it's um that I like to squash.

A

All over the commits oops commits um this is anyone against um squashing all of the commits into um you know one one one one before the change gets merged instead of multiple separate commits.

C

Crashing uh commits should help to clean up our commit history. If someone wants to go through the commit history in future, and if you can mark add the comments properly for each of the commits and people can follow it, that will be great.

C

We can squash all the commits at their logical points based on the need, so that users, when they go through the repository, they have a clean cut, commit history and they they will be able to follow on the commits based on the uh write up they give for each of the comments. That's what my thinking is.

A

Yeah: okay, that's a good idea: um okay,.

A

B

A

I was going to say some of the comments are just nonsense and you know you know, ignore those but uh um nonsense in the sense of just like added. You know just yeah, not interesting, but not really nonsense, but okay, that's a great idea, though yep. Definitely we'll we'll do that. um I just didn't want to surprise anyone if anyone was making changes. You.

B

A

To do it, um but um I just wanted.

B

You know the other thing I wanted to.

A

Mention um right now we can. We can build that, but you know, but there are, there are a lot of uh failures um due to you.

B

A

Unreal, you know unresolved class references like the job for test harness and what have you- and um there were some changes I didn't want to like. I didn't want to.

A

Just remove, like all you know, references to things that we might need to refactor um and that you know that's. That's kind of you know some open questions in the agenda. You know for that, but um yeah just wanted to mention that and.

B

Yeah uh scott- uh I was thinking whether uh uh this since this tck refactoring itself is a big task. Maybe we should create a separate branch. I mean the merge that you would do for the initial commit should that go in a separate branch. So maybe we could.

B

Divided into different issues, and maybe more people can contribute uh efficiently or I was thinking whether we should do that.

A

Yeah, that's a good of should. Should um we have more than one refactor branch that um um branch in the dck repo for different aspects.

B

I'm in just one additional branch for the entire refactoring: do we already have that.

C

Currently, we have a tck refactor branch created by scott, oh okay,.

B

Okay, so this the draft pr is currently uh targeted to the uh reflective branch. Okay and then I have to that's all. I have to say.

A

Okay, uh can you can you I'm I just changed? Can you see what I'm typing.

B

A

Okay, I wasn't quite sure- and let's see just bringing up the the branch list so so yeah we have um yep the tck refactor branch. um Let's see we should I'll just change, should we we should so.

A

We should use the.

A

Gck refactor um branch for the refactoring work: okay, yep yep, we yeah we do have that and yeah that'll it'll it'll it'll be good to have that, and um um I think this this this allows um the master or main whatever it's going to be called or.

A

Whatever branch to be used for immediate e10, tck changes.

A

In case we don't finish the refactoring and time for the ee10 release.

A

um Does that make sense, uh um like you know, put like like in in a few weeks um in october, we'll start seeing some spec api, um um you know ballots um and you will be able to um you know, look you know you know, look to bring in. um You know the specs as they change and um test changes um as well. um You know as it as they become you know available.

A

A

I'll just say that you know the tck refactor um branch may yeah, maybe complete or ee 10 are not.

A

You know we don't really. No! Yes, um because um but yeah yep, that's.

A

Let's see I'd like to go on to um um unless anyone has anything else to say about the about that, you know about that poll. Request um effort um go on to um the you know, junit 5 or test ng, and it it seems, like. I think I think, a lot of the um um efforts happening on um the other, the other um at the spec api level of ad and tcks.

A

I I think the trend has been that junit um 5 has been used more than test ng, but still I.

B

Think we, you know we'll.

A

We'll need to decide, um for you know, for the um platform tck uh refactoring of the tests. You know whether we want to use test ng or j unit 5, and for that reason I added you know. I added the item here and I I think test. Ng has more flexibility.

A

With regard to its flexibility to work with our existing tests, it might be a little easier with with testing g to um enable test ng than junit five, but um junior five is popular as well. So I'm not really I'm not really sure until we actually start making the changes in the platform tck the in the refractor branch to do one or the other. um I I think we have time to um yeah. You know to to to think about that. um More and um and yeah.

B

A

See how it goes when we do start making those changes, and you know if we hit it, whichever one we start with. If we hit a problem, maybe we look at re-evaluate and look at if it's easier with the other one, I suppose, but I don't know what what does everyone else think.

C

uh As you told, uh scott junit is more popular, but we have. We have a certain tc case like cdi and bin validation tck, which are using.

C

The test ng, but uh what's the greatest advantages or advantage of using test energy like do, will we get more productivity or will they will the movement of the uh test be uh faster or are there any advantages like there are more community developers willing to pitch in? If we have test ng or junit or or can we follow the high hybrid approach where we allow both? If a specs decides okay, there is uh it supports junit, then we will.

C

We allow whole of the spec to write test in junit and if the spec members are comfortable uh and they want to maintain it in uh uh test and we can allow them to maintain intestine g or if we have uh certain people pitching in for platform tck who are willing to help us and have knowledge in junit or test ng, we can specify or give them module based on the uh based on the comfortability and requirement like uh like what we get using test ng. That's what my current uh thinking is.

A

um So I I I think you know yeah, we, let's see so we should take some. We should take some notes as we go. um Let's see so I think, um let's see I'm gonna say um um I think I I I I think um test ng has uh better uh has um has more um um support for.

B

A

I'm just going to go back to the to the I'm going to go to the.

A

Let me add the link to the agenda.

A

Let's see oh page paste it in.

A

Let's see okay, so um I I I I think that you know tess ng, I I actually so I quoted um just switching to the um tck proposal.

A

Test. Ng has um um ex like ex. Like a nice external, can config configuration for.

A

I think it's external, that you can control it grouping of test methods, um so you can you can um um or it's in code. I don't I I think it now, but um they you know they allow um you're just a nice. um They have nice support for groupings or nested groups of um what is to be run or not to be run. That at least seem to me.

A

uh You know close close. You know close to enough to what we currently support in the platform. Tck, um you know be a key. You know the key words um uh groupings that we support that um um it just you know for users it might be yeah it might, it might be. um You know nicer, the um you know. Junit uh 5 does also have um what they call. You know, custom filtering, you know, via their launcher discovery. Request mechanism that can all you know can also be used so um and yeah.

C

A

Is so they you know both? You know they both have some level, but it just seemed like sng's advantage. Was you know the? Yes, you know the stronger support for for what you know what's enabled and not enabled um um which you know it's you know, isn't isn't really an issue for new for for things changing in ee 10, but more for any.

B

A

Optional tests that we, you know that we that we that we might want to bring in.

A

So oops, let me fix that. It's going to say.

C

Let's see what will happen to the test which, which has been already migrated or separated like they will continue to be executed as they are right, we will not uh enforce any rules telling that okay, these tests uh need to come back to be run in platform. Has a test ng test like we. There is already work progress for jax rs, and there has already been work on uh json, b and json b and yeah. So we will, there will not be. There will be hybrid approach right.

A

So what impact does does what the platform tck choose to use.

A

For test highness, I have have on I'm just at it's on the next screen, but uh next page, but on individual spec api tcks.

A

And the point was that.

A

Spec api tcks can choose.

A

The um um yeah can choose, but you know between I'll just say, ju unit 5 and test oops test ng. um But um I I don't think there's any reason to you know.

B

To change that.

A

A

And I'll just say I'll say you know some some spec api tcks will be um runnable against um ee containers.

A

And uh ee implementations um with the um platform tck needs to be able to run those tcks directly.

A

Are the user just runs them separately?.

A

um You know it isn't um um clear yet, but uh I'm just gonna add that at the point at that point we talked before about the platform. Tck will want to be able to run all of the different standalone tcks, but um um I'm not sure um yeah, I'm not sure. That's you know that that should be a requirement.

A

A

You know for those tcks with regard to running under.

A

um Under platform tck yeah, it's like why why.

A

Yeah yeah yeah, why you know why should they look why you know why run them on the platform tck? I think the only the reason would be so that um just for ease of use.

A

So I I think it's yeah, but I don't know this yeah. We could do that yeah. We could integrate them, but um I'd say it would be less. You know work to not integrate the other standalone pcks into the platform tck, but let uses directly.

A

Because I I think I think.

A

I'll just say this: this yeah this might change right, because if we can do if we could integrate them.

A

As if we could integrate the standalone.

A

A

You know they would be easier to run yeah.

A

B

Yeah hi scott scott, uh maybe you can share the uh gender, I think yeah yeah, even though we are looking at the agenda directly but yeah for the recording purpose. Yeah. Let's see.

A

Hi lucas welcome.

B

Hi, sorry, I'm right, I just had other stuff to do.

A

That's fine, let's see.

A

A

A

A

Let's see I'm looking for my chat control can can someone post the um um the agenda link.

A

And lucas, do you do you need the agenda link?

A

I don't know who just that someone just asked you have it? Okay, all right and just to let you know we, we are recording.

B

I saw that okay notification.

A

Okay, good, uh let's see okay, so yeah, um I think the short. The short answer is that um spec apis tcks can choose test ng or junit 5, whatever works for them, um I think from. As far as I can tell from the user perspective.

A

That's the person running the tck. um I don't think there would be made any major differences other than maybe the way you enable and disable different tests. Your groups of tests um will be a little different um between the two.

A

Right, I think the important thing now is, for you know, spec api tck um tcks that have been started or will be written to you know, have the spec api teams that are going to own those tcks to do what they feel they need to do you know, rather than for making that this decision for them. So if the platform tck does choose to use one or the other, I think that will kind of that.

A

Would that would be, for um you know any technology that we do, that refactoring for and just yes since lucas is here. You know just to pick one of his um many projects that he leads um persistence like let's say, for example, we do that we refactor the persistence test in the platform tck um and.

B

A

It's kind of done in the platform tck level and then let's say the persistence t api team wants to take over that tck. um I think a lot of the work will have been done for them in the platform tck.

A

Then we can just move the you know the sources to the persist, persistence, project and- um and let's say we did test, we started with test ng and the persistence project wanted to switch to junit, 5 or whatever, and that would be fine. You know no problem there, so I think we're okay. There.

A

B

A

For any of the specs that are already doing their own ref, you know doing the refactoring. We wouldn't do that in the platform tck like jax rs, I mean our restful web services.

A

We wouldn't do it for um um for batch. We wouldn't do it for um yeah, and you know json, uh b um or um or yeah any of the other ones.

B

A

Have already been, you know doing it in the platform level, so you know we'd, anticipate it being done at the spec level. Instead,.

B

uh I have only one node to test ng about a decade. Maybe 15 years ago I've added a feature to test ng which allows running junit tests.

B

It was able to recognize what in which framework to test, is written and react accordingly. So the only requirement was turn on some switch and have junit on the class bar at the time it was for junit 4, but eventually we could work with test ng team again and uh resurrect that feature so.

B

At the end of the day, it could be possible for the platform tck to use test g by default and allow running all sort of tests, including junit, once at the same time,.

B

uh But I'm not sure it was the state of that feature whether it was moved away or how it works. These days, as I said it was, I don't know, 10 15 years ago, so.

A

huh That's that's pretty interesting uh I'll, just say I'll, say many years ago, yeah, let's see.

B

I have used that I've used that or yeah I've used that mainly in netbeans or for netbeans, to allow their tests to be written in both while having also one testing hardness and.

B

Which is able to execute both, so probably similar approach can be taken by the platform display, be it based on test ng or juni, but generally it should be possible to implement.

A

B

For whatever, whatever the other option is, and this way integrate with those using the different framework.

A

Yeah that'd be cool.

B

uh As you wrote it, it could be, you could use test ng and run junit five test via special runner or the other way around extend junit 5 to allow running test engine tests. It could work both way. I believe all thanks.

B

And I hope that's possible.

C

uh Scott, uh you are sharing different tab. I guess you are typing on the agenda like the share is of different uh tab.

A

Oh, I didn't oh, I didn't I okay. I thought when I was switching to a different tab, that um the different tab was showing up: okay, um uh okay, yep! All right. Can you yeah? I is what I'm sharing now in sync.

C

uh It's uh like uh quackers uh tab, which has some jack forest test. That's what it's showing up.

A

Oh, that's, okay! Let me, uh let's see, stop share and.

A

A

A

Let's see, let's go share the um the desktop.

A

Is that? How is that? Is that um um showing the agenda.

B

uh No, uh it's still the caucus for me.

C

Yeah, it's quackers.

A

Oh okay, let me try.

C

A

uh Let's see share screen, that's true.

C

A

C

A

See? Okay! Sorry about that, all right!

A

A

A

Let's see so, let's um can we jump into um um um the restful web services? um Proof of concept work that.

B

A

Has been working on and um I I I added a question, I don't have any answers really yet, but um um but we wanted to know you know, do we still need the um the porting kit interfaces and I think it was like there was like what the ts url um um interface. um I think that we identified that we that we um needed or something like you know something with um yeah.

B

Yeah uh for jack saurus, I could see that uh only one single method for uh get url that is used to get the url of the application server being used. So that is why the porting kit is used for jax rs.

B

So in the comments it's written, if any other application server uses or or creates a url in a different way, then they would need a class implementation for that. Otherwise, the whole porting kit used within this jax rstck for the tests. I have migrated okay, uh so that is only using the get url, which is a very common one, but I um so yeah. Maybe in future we may require any different implementation if we see any other application servers. Otherwise, I think uh this porting kit dependencies only for the get url uh yeah.

A

um Okay, great.

A

um So it in the.

A

Drafts, you know, you know, pull requests that I had started. um um I you know anyone anyone who that's built um um the branch. The topic branch um sees that there's like lots of uh build failures and there's a lot of them. You know a lot of the failures are references to the java test. Harness and the question I had here was.

A

I I think um you know there, you know, there's some tests that are, you know that depend on the test, harness um in some way um directly or indirectly, and I you know you know, I think that we'll have to analyze um the use and figure out. If we can, you know just you know, remove or if we need to replace any of it and um it seemed like a bigger task than I wanted to do right now. Would you just to get that pull request? Yes, you know um available, you know the the continue.

A

The the ability to you know to have the separate maven projects um set up. um You know shared for others to contribute to um going, and um you know I I think, there's there'll be will be changes like that that you know that will be available for people to look at that want to help out um and then and.

A

You know so I I think the the choices really are.

A

If we just remove all of the java test, harness references um we'll be able to compile the code um if we just like ripped it off, ripped it all out, but then we would kind of you know we might be left with problems later that, where we didn't replace it with something that needs to that serves a purpose.

A

B

A

B

What I observed from the uh after building the code was that uh there is the status method, I believe uh comson java test.status, so.

B

That probably needs to be replaced with something else. This status is used uh in a lot of places uh to get the uh final test run status. uh Maybe we could uh replace that with something else.

B

uh That itself could uh uh remove a lot of dependency on this jtms.

A

Right: okay, terrific.

C

Also, along with the status there are, there is a another parent class which all the test class inherits. I think e test, or something like that. That also has a dependency on java test hardness that has code related to java test hardness that also we need to remove and, as alvin said, yeah uh status um like if we uh for replacing the status, we need to know the technology which we are coming up or using to or we need to write a status class to and encapsulate the state test run status.

C

I think we need to have a deeper look into the status uh class for removal and migration.

A

A

Good, okay, all right that sounds that sounds pretty reasonable.

A

Let's see so we have about 15 minutes left. I think um the the next topic um which which, which.

A

I think is the only well I don't know, I don't know if we can do it, but um but if we can automate, you know the switch. You know the um switch to our killian and shrink wrap.

A

I think it would be. You know you know, it'll be more reasonable to do. We've lost lucas it'll be more reasonable to do the um refactoring, and you know quickly.

A

If, if um I mean I don't know how many, how many people will be contributing but um yeah regardless, um if we have two um two million plus lines of code that we have to manually change um yeah but yeah we'll make this yeah there'll be a lot. You know, there'll be a lot of mistakes and it'll be very time consuming to make the change. Oh hi lucas welcome back um um it'll, be very.

B

A

Consu no problem it'll be very time consuming um to make the change, um um but um um so yeah. I think I think it's definitely worth trying anyways to um you know to automate it, and um I don't know if we should. You know I don't I don't yeah, I don't know the best tooling um yeah. I included a link that came out of um the servlet mailing list. um um Yeah, that's stuart on douglas um wrote some you know tool tooling for um quarkus that walks through the java.

A

You know test sources and rewrites the um the java test code um and it adds in yeah, killian and um oops. Just notices. Hypo um adds in uh yeah, achillian and um shrink wrap calls, and um you know the um you know it just in case. Not everyone is aware.

A

um The shrink yeah the shrink wrap api is just is a um api for assembling uh uh jakarta application archive, and so it's just um basically we like you know we need to you know you build you, build jars, you put files in them and or elements in them and um deployment descriptors and um add jars to ears or wars.

A

Add your wars to the you know, to the error, and um it's that type of code where we would basically, you know, we'd need to kind of walk through the tests and um add in the you know, the imports you know for um for shrink, wrap and use that you know that api and we'd kind of have to walk through.

A

You know um what is in that test archive um and yeah. Maybe we should be. Maybe we should be walking through the actual archives themselves, like the generated archives from you know from the current tck, um and you know, maybe that's easier to like to walk through um an actual generated archive and map that to the test sources. I don't know, um but um yeah so like what what would be the most expressive tool that you could yeah that you all would prefer like for doing such a conversion?

A

If, if you, if you, if, if anyone has any preferences or like you know, is there a lang, particular language or tooling that can best handle this? You know rather than java, or is java just as good as any other.

C

Like uh uh alternative is the scripting we are thinking about for automation,.

A

um Yeah this yeah, this yes scripting to ch.

A

Should you basically change all the you know like there's two million lines, two million plus lines of tests in the platform tck- and this would just this would be automation to you know it might not do a perfect job, um but it would do it would um um do most of the code changes to switch to shrink wrap and if it could do it all, if we could do it, a hundred percent correct, that's even better, um of course, but but that's the you know the idea to avoid having to make two million two million you know um chain, I I guess we I mean we wouldn't be changing all two million lines of tests or two million plus lines of tests.

A

It would be more like the I think, the test, the main test class, the client test class. If you will, that um um would would you know it would would which would be probably be changed to have the um the shrink wrap calls to to assemble. um um You know the archives um and currently that lot the logic is in the the ant um build xml script. I think in most cases you know driven yeah, driven by ant, to build the archives and.

C

Oh yeah, we can use the shrinkwrap, but I don't know how much we can automate the dependency which we like. If I want to add a package uh to the war or say some of the jars to a particular war. I don't know how much we can automate to an extent but yeah we can use shrinkware but adding additional packages based on the war which we need to create. I'm not so sure I will look into it.

A

Yeah, it's it's! It's not an.

C

A

It's it's just this. This is just to do a re uh mapping of what we currently are putting in each archive, um but using the shrink wrap api to express that um and so like. If, if like, if you like, if we wrote a road code to walk through the you know, the the the um archives.

B

A

We generate from the platform tck, you know. Currently um it probably wouldn't be too difficult to see all of the elements that need to be reproduced right and like for classes there's a class. You know we can get the class name um of a class from the class file um um and um or I can do it at the source level- I'm not sure, I'm not sure which is better, but um um but you don't yeah. So I get, I guess.

A

If I I guess yeah, we really need to see some proof of concept that that shows that can be done. I guess, and then we go from there, but if anyone has any ideas about the best tooling to use, then that would certainly be welcome.

A

If anyone has preferences for how we try it, um if we don't, if we, if we don't, do it huh like um how how how long uh like how quickly how quickly um um okay, you know like from the from the um um jax rs um effort, how quickly um was it for you to um you know now that you've done it a few times like like how quickly can you add a test um to what you've done so far like a new test, that's using sprinkler, shrink, wrap and to convert.

A

Let's say one test: is that an hour or a day.

B

Yeah uh for jax rs, uh um I have added around 400 tests for by now, uh so for string, wrap was used in two modules of tests, um so uh yeah actually uh uh most of the uh migration to the string wrapper and those things uh after the framework was done. It was easier I had, to probably uh you know, add the annotation, the right annotations and the deployment method. So I I don't think that would take much time, but getting the framework in place is the difficult part so yeah.

B

It may also depend on the.

B

On each component, but for jax rs after uh adding more tests after the system is in place, it's easier for now.

A

A

Tess is easy.

C

Also, it depends on the like uh configuration like some.

B

C

Doesn't have database dependencies or security certification dependencies so depends on the test from module to module like websocket I was working on. There was no dependency on database uh setup or configuration, uh so the test uh configuration uh setup was easy, but uh if we go to some other test like jdbc or jdbc or male uh test, then there will be a lot of more configuration which we need to taking take care of which might not, which we might not have visited so far. In.

C

Experience which we have with the current separated tc case, so there are many configurations which which are unknown, uh which we need to take care in some of the tck or when we migrate whole of the platform. That's the concern which I see also the security hasn't been touched at all. We don't know how much our colleen supports installation of the key stores and other stuff um which which are which is a black clock box to us currently yeah.

A

I'll just I'll say every extensions.

A

A

A

Implementation, specific.

A

Deployment descriptors is not understood yet.

A

um I think there's ideas for how to do that, but um I think that's another one, like you know like there's.

B

A

The glass fish deployment descriptors that yeah, we know the names of those. But what about you know? What about um you know? You know wildfly or um you know whatever all the other implementations deployment descriptors, um where the user knows the name, the names but yeah. We need something dynamic.

A

That can kind of add, you know, add in um add those in, and you know it's almost like. I think we, you know, maybe it's an api to extend to the implementation being tested um um or maybe like an api. um Yeah is one one option: anyways.

C

Also, we have a concept of vehicles right. We deploy er for ejb vehicle, I guess. uh While we do um individual standalone tck, we don't encounter that, but uh I'm not so sure how we will implement for platform and how we will have handle the string, wrap changes to switch between ear or war files or how it will be handled, I'm not sure scott. You might have some ideas on this.

C

I just wanted to bring it bring this up during for discussion.

A

Yeah, I I was thinking.

A

I I didn't do anything, but um I was thinking that the vehicles have to like um just be refracted out so such that, like you know, if it's like an app client or um you know, web client or the you know, um you know all you know the different. You know it just becomes an aspect of the tests themselves and I don't know if that's like in lining um some of the vehicle.

A

You know the vehicle, um um the runtime classes into the test, or maybe you have it, as you know, as as a library in some form, you know where that code is kept as a separate thing. It doesn't you know it it. It doesn't matter as much as yeah that concept kind of needs to be. I'm sorry. The logic needs to be included. That's part of the test um like if you like, for all the apa tests.

A

If you can't run with all of the you know, you know if you can't run with um use a transaction versus you know, jta um container container managed um um you know transaction or um you know it's. We wouldn't yeah. We would lose something and we don't want to lose both. We don't want to lose those abilities, so yeah yep, that's definitely uh yep, so we need to yeah. We need to figure that out.

A

All right and all right, let's see.

A

Okay, we actually um all right, we we we, we have a um another call this after you know this afternoon or for some of you for everyone else. But me that's like going to be tomorrow.

A

um So maybe you know you know we'll. You know be able to continue from here, but.

B

A

I think we are out of time um but be before we um before we end does any anyone want to did anyone have anything else that they want that they wanted to. um You know, add to the agenda for that, for a next call or or to close with anything you want to say before we finish.

B

One thing not related to backstage or anything I've added, a pointer to that test, ng mixed mode to the chat. If you go to chat, you will find a link where that mode is documented. Let's.

A

See, oh okay, let's see.

B

And maybe you want to put the uh put it into that into agenda so.

A

Definitely um yeah, let me see, let me copy that and if, if, um if, if you send me a um like, if, if you request edit access um for the next, you know for the next call or whatever that you know that that you know that's welcome, um so we get more people that can edit. Let me just I will go, go yeah for this one I'll go ahead and do that, let's see!

A

A

Yeah, nice, okay, thanks.

C

uh uh One more last question: uh scott do other uh like do. We need to write cq for junit or test ng if you have started uh using those or those are like how they will be taken care of.

A

Let's see so what what's what's? What's you know what test test ng or j unit, but what? What about them? uh I.

C

Like uh if you start using those uh components like junit uh or test ng, are those licensed technologies? Should we raise cq for that like? uh uh uh Are they.

A

C

A

B

No, no they're, not like yes,.

A

B

But the cq will have to be raised and the question is whether the tck will redistribute these artifacts or just use them. Because in many.

A

B

We are using the either junit or test ng as a test dependency, so it's works with and it's almost instantly approved. But the point here is that those dependencies are not those being redistributed but for the tck. I think it will be required and it will have to be set explicitly that tcpa project will redistribute these artifacts.

B

A

Yeah, yes um yeah. Let me add that under let me add that, under um the test.

C

A

um Let's see so, basically that I'll just say um will test ng oops, we'll test in g j unit 5 be distributed with um platform with I'll say, with with the platform tck as the question and.

A

I'll just say we can, we can expect um to do a um contribution.

A

um Questionnaire, I think it's called.

A

Eclipse cq requesting to include um those um libraries yeah with the platform tck um and I don't know um what that will find that yeah so yeah. So the.

B

I think it should not be a big deal, it should be approved, but it's it needs to be done.

A

Yeah yeah, I got it.

C

Yeah, it needs to be done. That's it.

A

Yeah, um okay, good all right, that's an excellent point!

A

um All right! Thank you um guys and um I'm just gonna hit stop on the recording.

A