Jakarta EE TCK, 5 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TCK call #29

Description

April 5, 2023 Jakarta EE Platform TCK call #29.

Minutes can be viewed via https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#bookmark=kix.35hlwwtsxubg

A

A

All right recording is in progress all right and let me just paste the agenda once more for everybody in the chat room again.

A

A

So, let's see see, that's um um yeah, we have we yeah. We have um some items on the.

B

Agenda um already already here.

A

Which is good and um let's see so, um you know the first thing was um kind of um go over the um um I yeah or mention you mentions the um the you know the track and issue for um for refactoring issue. You know 11 26, but um but also going over the um the module owner list as well and just want to kind of kind of gloss over what we're going to try and get to here today um and um drill down into some of them all.

A

You know the different tests, some of the different um specifications or or Technologies our modules mentioned in the issue, um and we have some feedback on it. um The next one, which is you know, implementing the different test, vehicles for um um the platform, tck aspect or the you know the platform testing, if you will, um um and um lastly, I I'm- not sorry not at lastly, but um I added an item um which you know, basically um it um just to to bring more um knowledge out um about about.

A

um um You know creating Stan. You know you know Java SC or Standalone tcks for the different specification waves, so they can be used to validate the different specifications um where those Standalone tcks are then later extended um for the it. For the platform, tck asked the what will be the new platform tck aspects um where the Testament is done against an actual ee containers, um and um so it's just you know not to get into that yet, but that you know that you know that was.

B

A

One of the make sure everyone's on the same page there and um let's see, do I- need to accept this I think everyone should see it. The thing Ed added um time.

C

Permitting yeah yeah.

A

um Conditional appeal for co-re co-release coordinator from the ranks of this meeting, okay.

C

um And I left out a word: ee 11.. Oh.

A

Okay, um release yeah great um and um yep. That's that sounds great. So um so just you know just to kind of go over, so we have a lot to cover. Let's um um see, I I'm, not sure is, uh let's see let's um but yeah. The the tracking issue is a pretty big one, but let's just see what see we'll just see what um let's look at the con. This actual comment here on here and uh um everyone should see the um tck refactoring roadmap. Now, um if you didn't please.

D

A

D

Scott basically, I have added this comment so that we know that people who are working on the model who are currently working on the more deadline, doing the refacting for the specific module. ah Okay, yeah I have taken up the websocket, which is on the bottom of that list, and uh Alvin has completed work on Jack, sorry and I'm. What I have started work on JTA so so I have added my name today.

D

So there are many modules for which uh owners are not present and how to deal with that and are there any willing contributors who have knowledge of ejb like ejb, is a big model. The first there are three ujp models like egp3 to egb300 ejp, so those are very huge models according to me and which require a lot of knowledge of ejp, so how to go about that so that and how to plan for completion of these models in El for E11?

D

So so that's what my thinking was so I added. This comment.

A

Thank you I think that I think that very you know very well and and just just for just for for just just in case someone's wondering you know, I I, uh last fall, I um I signed up to to work on the jpa, I haven't started yet um so, let's cut you know, so maybe we should um indicate yeah.

A

You know so I'm kind of like signed up to do that, but I happened to actually started started yet I've been busy with other with other things and just haven't gotten to it yet, but just to throw that out there. So people are aware of that in case. Others wanted to get started sooner.

A

um But what you can you know what what you kind of see from from this information is that um you know there is a lot of work to refactor the two to three million lines of tck code, and it will take time and I just wanted to add that um you know the individuals that are currently doing. You know you know particular parts of this shouldn't rush um and and, like you know, Rush their pox in the sense that you know that we should do it.

A

We should do the complete um task and not um um you know like leave out the documentation, changes or or or or or or that and um one of the yeah one one piece of feedback I got um on ee10 was that we did Rush um on some of the refactorings and I. Think it's true. You know we could have taken more time in some areas and we there were just so few people and um you know so. We rushed I just kind of wanted to kind of address that whole aspect of you know.

A

You know not spending enough time, necessarily on the on individual tasks and rush into the next one, because you know we're trying to meet a schedule. I think yeah, I think well. Yeah I just wanted to bring that up that um you know um um yeah. We can get volunteers to work on the others, as we demonstrate how it's been done for the ones that are already initiated, and you know but yeah otherwise, yeah it'll, take time to you know to you know to accomplish in the work so yeah.

E

So I I have a couple questions I mean one is: um uh how are we gonna? How are we incrementally introducing these changes? So, for example, uh was it you uh Guru that had done an egb prototype?

E

That is this. Your PR.

A

Oh, the websocket pr I.

E

Think no I thought it was EGP refactor.

E

Vehicle, oh my badge,.

D

Yeah, that's the Via from batch, which we we can use for as a reference. It's not uh in the platform tck uh refactoring code. As of now.

E

ah Okay, because that was my first question is: is there um you know what what's the blueprint for refactoring one of these these modules and how does that fit into the current um app based driver? Are we going to have two drivers or we have an amp base, one for the Legacy stuff and then a new maven-based one for the the things that have been refactored?

E

Yes, how are coordinating uh incorporating and producing? Because another thing we need to do a better job of is producing milestone, releases of the tck, so people can be testing and warn we're trying to free up the bottleneck for the specifications as the waves are being moved through um making you know, making uh the content available as soon as possible. As soon as it's ready, you know versus uh just having to rely on producing a big final tck blob.

A

um So so so um Alan um I mean yeah for yeah, first put into a Wiki and I I copied it into um um on the refactor branch, um um a uh in a notes, folder a design note um to try and capture um an understanding of that I. Don't yeah I, don't know if this is what you're well.

E

B

E

B

Was more specific for a separating uh the tests into a standalone, pck uh I think they? This may not apply uh mostly for uh refactoring the platform tck modules. uh This was mainly intended for separating the test out of the platform, basically into a standalone using Jax RS as an example. This may not apply for most of the other modules. So, okay.

A

So it doesn't help.

B

uh In my opinion, uh like uh as per.

D

B

uh Using aquilian I think that is what uh maybe we should focus on uh to continue with other modules, so like most of the other modules like they run in different Vehicles, we can see the third point in the refactoring uh issue agenda like I, think that is something that we probably should be discussing.

B

um um uh uh When I worked on the Jax RS module uh I was able to use the aquilion because it's by default we have the select container, but for the other modules I think there are different Vehicles, like JSP, applying ejb Etc. So I think that part is not very clear to me as of now. So maybe somebody can also comment on that. But how.

A

B

Implement the vehicles uh Guru had suggested to me earlier that for I think it was for batch or concurrency I think they had implemented uh different vehicles. uh Further refactoring uh I haven't gone through that much.

E

Okay, yeah so I think that's like the first thing we're gonna get a handle on is exactly what is the pattern for, uh because the the vehicle, the vehicle architecture has always been a little bit um convoluted for me. So I think if we definitely need to get that clear, certainly to be able to obviously do it correctly, but then also to open it up and you know be able to assign- or you know, create issues that more people have the potential to jump in and because.

C

E

Think that's I think we should certainly have an issue for every one of the modules that that Guru has highlighted you know, but then we need um like a Wiki doc on okay. This is how you go from the Legacy, um the Legacy uh vehicle approach and slash vehicle approach to uh um gen unit and arcillian. So let me understand what is this um this egb vehicle from the batch tck? What is that.

A

In the in the batch tck there's um um some transaction like JTA transaction tests that um um you know they they you know did you know so: yeah yeah Scott, you know Scotch joins sometimes uh from the from the batch team, but we'll see I'm here today, but um um they um um you know just you know, just have a like a comment like a common um way of um starting a JTA transaction. To do you know to do some of the of the work against um and um um you.

B

A

um So yeah that you know we could look at look at that. I I, it's been a few years since our our or something since I've looked at it I, don't remember um the the details of what of what he did but uh um but yeah he you know he's done that and um I I guess in um you know in the in the rest, in the rest, um tck um yeah, you know um um yeah. We have um you know that you know. That's all you know.

A

That's all using you know servlet deployment, but it's um you know that you know that's another example um and um yeah from a like from a shrink, wrap point of view. You know we're just you know what. Basically, what like you know, we're building the archives and um and then and then you know for the deployment and and then yeah you have your junit test that uses those deployments and um I mean. Fundamentally, you know that's one aspect, but then, when I guess, when you get into yeah.

E

Yeah yeah there were two so there's two convoluted Parts in the the current Java test stats vehicle.

E

Harness for me and and one is certainly the the creation of the test artifact, because it's kind of a convoluted layering of and scripts, which you know, I, don't I I, never really came to play the grip with so because we're incorporating uh you know, class path, elements from multiple layers of directories uh to build that up, um so that that was a convoluted part that you know it would be nice.

B

E

So like that, that'd be like the first step. How are we gonna? How are we gonna have to layer that type of logic into um are? We gonna have to have separate, Maven artifacts that are inherited by these? You know, for example, if I have an ejb test, you know they were, they would pull in a common egb thing, so that's going to have to first be refactored into um a common Maven artifact, and then they depend upon Etc.

E

You know that type of stuff is would be one thing and then the other part was you know. The actual launching of the vehicle um was a little confusing as well, um so I think we're gonna have to have just like one meaning and maybe we'll have to be in a separate meeting, or maybe we can just try and do it design wise over over email or or whatever, but I think the first thing is just trying to get okay.

E

Here's like a basic uh how this flow Works in terms of what the launch class path is and how that incorporates um all the artifacts that are being built for the current Target test and how those might map to an arcelian-based one, which obviously requires money than artifacts.

E

uh You know if we can like try and do some design sessions around, putting that together over um email and if, if necessary, doing a separate call or other calls to to try and move that forward, because that's certainly going to be The Stumbling box, as uh Allen is saying, is okay, but what's the approach so I think once we get like one understood, then there will be a movement where we can move this forward.

E

So that's why I was certainly interested to understand what um I'm not sure how to pronounce his name, but how the the servlet uh work had had gone on, what what he'd actually done there. So.

A

Yeah yeah and yeah, and and for those who may not be aware at at 5, 00 p.m. Eastern time um um um today you know you know we'll be you know we'll be talking about that, as um in.

E

A separate call he's in Australia, so there's.

C

A question about that time uh is that in the Jakarta e specifications calendar.

A

um That's so, for today's call I had updated the calendar last week for today's call, it's updated for that time. Yeah.

E

A

So it's um yeah. It's.

B

A

You just just it's a one-off, but.

C

Just yeah today.

A

C

Tck call for Jakarta e, yes, I see it. Thank you so much you're.

A

Welcome um yeah, the only thing I was going to add.

A

um um You know when, when I saw, when I see all of the um shared and common classes, um yeah one thought that it had come that had come to mind is just you know, you know, having shared classes is great and um the shared classes that we will need won't necessarily be the shared classes that we have now, but I mean there's no reason why we couldn't in like inline classes, if that makes sense, um that would create a law of duplication between tests, but it might make it simpler to in less less cumbersome to deal with the complexity at the same time and and then kind of um factor out the you.

E

Know I guess before worrying about that uh particular level. I think we I think we probably have should start at the vehicle level, because what.

D

C

E

Oh, my can you hear me now.

C

E

Can Okay um like it's? It's it's it's common to have well and so, for example, in the CBI and batch, which are our Killian base. They happen to use um test unit framework.

D

B

D

Unit but that's that's fine yeah.

A

E

Mc right, that's not super relevant because it's they're still just you know, generating made in artifacts that are run um to uh to uh the standard Surefire news framework um I mean we do have the notion of common classes. You know, but this is package that gets Incorporated. You know into the the tck artifact jars and then you know the run. Time is pulling in those classes or the test runtime displaying in those classes and uh archilian.

E

You know selectively remakes its own runtime class path, so uh it it actually kind of whittles down what you actually see in terms of either the in-memory container runtime or the artifact that's produced um so I think if we can understand how to take the test, vehicles and transfer those over into uh artillion and junit tests, so then I think it'd.

C

Be a little more straightforward.

E

Because it's possible that if that can be done, then all we need to do is transfer the the ads, the hierarchical and construct into a single, a maven project with a single artifact. That is the test and those common classes are just going to be classes that are available on the test. Artifact so I mean that's, that's how it works in CDI and batch or I'm. Sorry well, probably batch too, but um validation, so I think that should be.

E

The initial focus is: how do we switch from the current test vehicle ant, Runner approach, Java, test ant, Runner approach, I! Think we can understand that then then we can tackle the next piece of how do we actually refactor uh the individual test modules.

A

C

You know what can I share one little quick observation: I'm, quick, sorry to jump in real quick about this um I'll be very quick. It just occurred to me.

C

um I was at a demo from Microsoft internal um all hands, meaning a few like last week, and they showed a demo where they had a bunch of a huge number of selenium tests and they used a GitHub co-pilot uh to refactor them to um playwright, which is another thing that Microsoft did, and they were talking all about how this really helped them move a huge number of uh tests from one thing to the other, so it I want to put out there that maybe we should I could think about this uh as a possible approach to scale the work.

C

Considering the large sloc. We have yeah.

E

I've I've been looked at that at all, so yeah look at interesting.

E

So code I mean I, I, know nothing about copilot. Frankly, at this point, so basically what how do you use it? I.

C

Mean well I I could go back and get the details of this demo, but what I understood is that they um sort of used an API that allowed them to ingest a test and then tell GitHub, co-pilot and turn this from selenium into playwright, and then it did it and then so then they were able to basically script this thing and and had it thousands of tests and automate the process of migrating Okay. So.

D

A

And so you know, and what was the name of it again this one. But oh.

C

Well, this, this was uh how you could just say, add interjected with GitHub copilot, or something like that: okay,.

A

Copilot I I yeah I've heard of it, but.

C

There's an API to script.

C

Most people want to think of copilot I, think of using it interactively in an IDE correct, and this is a way to automate. It.

C

So I can I'll. You can give me an action item to uh Circle back on that, because that would really be if we can figure something like that out. That would help us yeah.

E

No, the only concern or doubt I would have in that front is how much training would it have had on Java tests is.

C

That I know I I, don't know, but.

E

You know it's crazy.

D

Sometimes well.

C

Yeah I mean I I, remember Java, test. Thank you, I've written some Java test tests for JSF and servlet, probably 15 years ago, I'm.

E

Sure they're still there yeah.

C

A

A

So from from my front yet from a ordering point of view, um is that like like like at what point? Do we need to start having platform? You know the platform level tests versus you know re like refactoring, just like like a junit, only like a Java SC um or you know you know, or you know, or whatever minimum technologies that are needed, like in the case of websocket tck. You obviously need a websocket like a web container. You know for that tck, but like doing like, would it like?

A

Would it make sense to do some of the work to create the Standalone tcks first and then do this in parallel? Or should we do figure this out before you know, starting to create a standalone tcks that are J unit? Only um foreign.

E

There could be a benefit to that if, in fact, because I I would have questions as to whether or not or how much of these. Certainly a number of these tests are going to basically just be centered on that technology, uh because they haven't been pulled out into a standalone test, so uh I mean I, guess it could help well.

A

I mean that's, that's the thing there's um and, and it's very um um it's not not necessarily straightforward to identify. You know the S. You know the stand the Standalone test, but there's like like in some cases, there's um like an sc folder, which has the Standalone tests under some technologies in another for other Technologies. It's you know not as obvious as that, um but yeah but like for you know, you know forever. We've created Standalone tcks from you know from the you know the CTS originally and now the platform tcks.

A

You know Source repo, so there's so there's kind of you know there are like Java, SC or you know, are staying alone, Standalone tcka tests that have been there. It's just like a subset.

E

A

No vehicles involved.

E

uh What that they had to have at least some so like no.

A

No, no there's yeah yeah like there's, it's I, think it's I think um there's like a classification. I forget if it like that, but they're called like like run time or Standalone I, think it's Standalone but like in the um they can open up one of the um like one of the uh examples: let's see it's in the um in the install.

A

Let me just open up like jpa, because that's I think that would be a good one.

A

Other and vehicle.properties um well, okay. Well, there you go, there's a vehicle or properties, but it's it's okay, so it's called standalone.

A

um So basically, um the the jpa um or the persistence tck that gets generated by the um um the platform tck for ee-10 um is is a you know. It does not use any um Jakarta or ee container Technologies. It's completely Java SC Standalone! All you need is a setup um like a class path. You know vrts.jte and ants, but um it's still you know it's pretty. uh You know, there's no uh yeah, there's no ee anything in in that and there's other ones that are like that. Well,.

E

Yeah, it seems like there still has got to be some depend upon the test. There's got to be something that's still providing uh the persistence context and all that stuff, though so I mean um yeah.

D

E

Even even even are there tests for integration with CDI like injecting the persistence contacts, it seems like it's. It's still not there's got to be some non-trivial yeah.

A

No CDI yeah, no, you know no um there's no CDI there's um but but but but the persistence, this, the persistent spec itself, does support um Stan yeah. You know Java SC,.

D

E

It's like that's yeah, that's that's a specific thing.

A

B

E

Don't know how that really helps, though, because what the concern is well, the one interesting thing would be: what is the? What is the runtime entry point for that Standalone container, you know what does that look like how's it building it's it's.

A

Not a container, it's it's just it's it's it's! So it's.

E

A

Api, it's an API and you and.

E

You basically there's still an entry point. That's passing in all this external information like what are the tests? You know. What's what are the tests? What are the test packages? There's still a JTV environment? That's somehow being used to set up some context for that Standalone container, whatever that is yeah.

A

So so so it looks so it looks like um like a j. You know like like it's it's Java test time. It's based right now, but in in junit it would just simply be. You know, junit tests that um half a persistence XML that identify that um you called a you called the jpa, bootstrap spec, um to create the pers, the um entity, manager, Factory and you'd. Get you you.

A

Basically, you know you pass in like the persistent unit name and the persistence provider finds the persist, persistence, XML, um um you know in the file system. Reads it and create you know, creates the pursuit. You know the entity manage a factory from that which you then can get entity managers, and so the junit tests would simply be. You know using that to create entity manager, factories and entity managers, no ejbs, there's no extended persistent context and all that. So it's it's all.

A

um You know it's it's, you know so nothing that requires a container okay and it's very useful to the teams, because it like it lets like the like Eclipse link or hibernate, or whoever opens jpa, who, whichever provider, to come in complete isolation, create their.

A

um um You know, implementation against.

E

The yeah yeah, that's, certainly a good one that should be a candidate for pulling out as fully functional Standalone test.

A

um And and so it's like first wave, it's like first wave there's the second wave, then you know, and then they just keeps building up and eventually we what we hit like the six I think at the sixth or seventh wave, and then you need the platform. You know the platform test so um um that yeah I'm, not against you know, starting this work. You know early I I just was thinking that the Standalone work could happen, could kind of coexisting and.

E

Kind of go forward, yeah, you're, probably right there um start with in terms of actually trying to grok the vehicle or architecture, is like take a simple set of tests that don't have them. There aren't many like uh GMS and see what would it? What would it take? You know to make that a a junit artillion based test Suite.

E

So I think that's actually I mean you can assign maybe the JMS one of I I. Don't have that issue pulled up, but I'll do that after the meeting with uh we don't do it now, um I want to take a look at that and try and use that as a basis for uh you know, come up what is the? What is the pattern? What is the pattern that we need to follow in terms of uh steps for converting from the Java tests?

E

Slash can't slash vehicle architecture to jnn arcillion awesome.

A

That's that's great.

E

um And so hopefully, we'll get I'll get some insight as to what uh all of a did with the servlet on that front. So you know, hopefully what he's done so and he has an active branch that he's working on or active PR. Is that how is he doing that work? You know the server.

A

Oh, oh, oh yeah, yeah yeah, the um yeah. He has an active branch that he's you want yeah that that's. You know um um that he wants to uh merge into the refactor branch which, um uh let's see if we just pull up, pull up the um I'll. You know paste the um the pull request in so we can. We can get his um oh here. It is and he's gonna work on this for a long time. Yeah.

E

A

um Yeah there it is there yeah, yeah, it's so it's so he's got a topic branch that he's been been going. uh Let me just paste that in as well uh um so um um and uh yeah, so I I was just going to mention one thing about that: um um um I was thinking that you know the implementation should be able to validate against um um his changes when the you know when they're ready in the in the statisticated refactor branch.

A

But all all these changes that go into the tck refactor brand should all be validated against. Hopefully, multiple implementations.

A

um And um um so yeah, yeah so and yeah I hope, that's I, hope, that's something that we. You know that we can see um happen and I think that would be a good way to uh fine I find issues for code review is just I mean I know we have people with superhuman strength, um I I, don't know I why I was looking at the 60 000 line, pull requests um for the brief when we did the the ee8ee9 refactoring. My eyes were just going crazy with trying to review those huge pull requests.

A

D

E

Yeah yeah it'd certainly be good if uh you know, as soon as possible, we're producing whatever Milestone artifacts out of that TCP refractor branch that we can.

A

So so yeah, that's actually a great point. The um so one of the ideas here is to keep the specs on ee10 as long as possible um so that we can actually have Yeah ee 10 implementations that can help validate as well as existing compliance specs.

A

You know that, aren't you know, haven't yeah don't have to you know. You know new new changes in them, yet so we're kind of create yeah. We kind of have this nice, pure environment, where we can run, we can validate I, think you know things work at some point we'll have to bring. You know actually start bringing changes in and then we lose that. But um it's a you know nice thing to have. While we can yeah while while it lasts I think.

D

E

I mean I so I'm, not sure so. For those who aren't aren't aware, Ed had been requested that head be Ed Burns, who just left be the um the ee 11 release coordinator, I'm, not sure that he's accepted that, but um that's certainly what it seems to be hinting that into agenda enemy added, um but I think there's going to be some pushback on what the time frame for the the releases. If he does that, so uh you know one thing we can especially on regards with regard to this.

E

This the bullet point from him is I mean. Maybe we have to add a you know, blocking issue that we get uh the tck refactor branch to um you know a semi-usable, some level of stability and usability for ee-10 releases. You know before we start moving the tck forward to EE 11.

A

Of working uh before we start moving it uh all the way to actually have changes.

A

That changes you know longer can validate tcks with implementations.

A

I'll just mention the meaning. Once you add, the 11 changes in pcks will not work until we um iron out until we solve all pck failures, with some implementations.

A

Which, okay take a whole lot more time to say I mean one time. Is it object? You know subjective, but um um you know with ee10 at some point early on we've brought changes in and then it was I think it was like it might have been like nine months before we had worked through. You know the combination of fix and implementation problems and also tck problems, and where the problems were you just never knew. You had to chase all possible areas to find in the causes, but.

E

Yeah, especially um the later changes in the later API is really bogged down. How much we can do complicated testing.

A

Okay, so we have 15 minutes left we kind of, let's see so what didn't we do so I, so I I had added this. You know about following the order of specification waves which I I, I I I, probably pretty much um I, already kind of stated that you know glossed over that and um um I.

A

Don't know if there's any more feedback about um so so I guess what we we've accomplished today is you know we can start working towards the platform tck tests and how they're going to work by figuring out how the vehicles will work and kind of like in parallel that work can can start, um so it doesn't necessarily have to be bottlenecked or we don't have to do other things first, so um yeah that can yeah that can be accomplished um what I I was trying.

A

Yeah I was trying to um to get the point out, though, also that um yeah I think for 11. We should um you know, um follow the idea that one says a spect Outlet completes that if we make test changes um you know we need to commun, we should communicate um with you know with the spec ballot.

A

You know the specification committee um you know so that they know you know that you know that the valid and we need to go back to first wave or a particular wave to a particular spec and kind of read. You know do that if we, you know like to somehow validate that that those tck is still pass I, guess um in some fashion and then to coordinate that and I.

B

A

With a separation um where, like that, like there may be Standalone tck tests that are in the platform, tck repo, but they're isolated from the um uh from each other, you know from the platform versus the Standalone tests, so it should be more obvious when someone like, when there's a pull request to change something, if there's a change to a common code, it may not be as obvious immediately that um that it's impacting a standalone test and yeah I.

A

Guess that's like another thing and another issue um but like if someone asks like if someone asks if we, if, if this wasn't handled in the past I, don't think you know we really know um because it it just it just the repo was just so big and there's the organization doesn't um allow for it and um I think there's already like a platform um issue that specifies that technology should be separated um as well under the tck um sorcetry in you know by um you know by that technology, and you know that would be I guess that would be good.

A

um You know if, if possible, I know, that's not currently done now. It's just a big. You know mismatch of different Technologies. All over the place, but um you know if that can be done, but um if we can at least have Standalone versus a platform level test that would be great and I. Think this you know.

A

In some cases the Standalone test will move to this specification teams right right, I know: there's some specifications teams that just haven't been active for a few years and that they're probably not going to take them and I- think those tests should just stay in the platform tck. If no one else wants them, I guess but foreign.

E

We are certainly going to have to prioritize or have an unordered list of how we're going through these refactorings. uh Certainly, the waves would be one prioritizational ordering to look at.

E

D

E

Sounds like your. Your concern is a little different.

E

I mean what was there an example in ee-10 where the specification was finalized and then there still were in tck changes made. You know other.

A

Than no no I'm just saying I, you know we didn't really or I I know. I I I didn't watch for that. When we were, you know in the in the um you know in when we were fixing, you know you know platform or you know container. You know container tck failures.

A

um We may have overlooked in some cases that they were Standalone tcks impacted by some common source or a you know, a source change I mean we were very you know we, you know we were very um driven and um to solve to solve problems and um yeah. So I I just couldn't say that we didn't do that. We might not have we or you know we might have I, don't know I I. Just don't think that we I, don't I, don't think we you know. Necessarily, you know you know spent you know.

A

Pay you know would have noticed that we, you know that had been done. um um I know there were some persistence um changes um you know test. You know, you know, you know, you know, you know test chain. You know tests made at some point. I. Don't really recall when that at what point? In the release, but I remember there were some and I know.

A

Persistence is like in the first wave I think you know um so that we might have done that there um or might, or maybe not I, don't know, um but I definitely I definitely have not heard of any um of the follow-on problems that can happen.

A

If that, if we do that which are like like, for example, if an implementation um um is compliant against a uh ratified specifications tck um in a later, you know look at a updated tck and they notice that they don't pass it anymore and they yeah they'll and they can either challenge it or they can change a spec, but I I know.

A

There's definitely you know, there's definitely teams out there in open source, who will definitely question uh and and challenge that rather than make change um in the in that circumstance that that didn't happen, I didn't see any evidence of that, and that would be like an indicator that yeah we missed something like that, but um this is more just trying to be proactive about not you know ensuring that doesn't happen, yeah with the planning this this time around.

E

Hopefully, a lot of this just is an artifact of separating uh I mean everything should be runnable. You know each of those top level uh component technology type should have its own sub module or and artifact in the uh the refactor tck Reborns yeah.

A

Let's go take a one second break I just got to open my door, but.

A

My dog's gonna keep barking.

A

But yeah yep yeah yeah having them ice having them isolated. Definitely it definitely helps.

A

Let's see I'm gonna see I'm gonna stop sharing a second here all right. Let's just chatting.

A

And uh Lulu can say hi say: hi everybody hi.

A

um Is so is there anything? Is there anything else that we should uh get into or did we do? We miss anything.

E

um So, what's what it what's the structure of the uh the current tck refactor branch? Is that a is it? Is it maven-based or is it that's still a work in progress.

A

um So so yeah, it's um so the team, the tck refactor branch um is maven-based and um we we had started it um for ee-10 and we I think it was like October um or September, maybe actually September.

A

When we were developing ee-10, we had um you know we abandoned it and um just um um you know when, when you know you know back into the master branch and continue for ee10 with that um and and looking back at it, we, you know I thought we should abandon it and just start over from scratch, but um others you know voice. You know had the opinion that you know no, we can really. uh We cover the work that we already did and it's not you know it, and um you know so.

A

You know some cleanup for the cleanup was done and um yeah people you know people shipped in and uh helped out and um yeah it it yeah. It builds. um You know the multi, multiple mavens, you know projects Sub sub modules and um you know for different Technologies and.

E

So is it all in sync now with um in in terms of the actual tests.

A

I mean it doesn't, do it I mean you? Don't we don't run any testing, but it you know it just compiles, you know we can compile and build, and um but we haven't, actually you know um done in the intestine. Although I mean there's some progress that uh you know that people have been making like like the Surplus tck is ready to merge in so that would obviously work and others. You know there was a pull request for websockets.

A

So obviously that would you know that that yeah those would be more functional than just compiling and building yeah, um but um but yeah it it builds. You know it can everything builds and you know compiles. You know as it is I don't know if others have feedback on that as well to add, but.

E

Okay, well I, guess uh building that and see what its structure is and then um and then try and like I said, try and start a discussion around um the JMS test as uh something to understand how we're what what we would do to re to update it to use our Killian and junip and what uh the pattern in terms of replacing of the junit I'm.

E

Sorry, the Java test and vehicle architecture with the LA, the former would be um you try and get that which he defined, and you know because once we get that defined, then then we can start creating issues for refactoring all the technology trees and then uh you know actually recruit people to help out with that, or at least that we would have the ability to understand more what the scope of the work might be.

E

Is it you know, that's going to be one tension is uh what are we going to have to do for 11 and can we can we put a stake in the ground and said: there's there's going to have to be some blocking level of um accomplishment made. You know to.

E

4E11, you know and get get by by back or Buy in on that that approach.

A

um Yeah, so so I I, don't think we can yeah I, don't think we can do e 11. You know we can't progress. You know forward on the 11 until we have you know implementation and the tcks that implementations. So it's it's kind of like you know the work that is needed, I mean like there's, really no alt alternative.

A

um If the work is happening in you know in the refactoring, that's where the work is going to happen, um I mean it would be. This like the technical debt is very, you know it's very cost of it once we solve it then, like for ee next is going to be easier for teams to contribute to and we're going to be able to scale so I, so I I'm all for solving the technical debt.

E

You know yeah, it's that's. Certainly our position but um and I I again, I I did talk to Ed Burns uh about you know. That is that's a concern we had for E11 and um certainly that was a concern with the current road map. So that's why I've seen you know the conversation with him seem to be leaning for uh that this tck there's some base level tck work that needs to be done as a blocker for E11.

E

So you know there already is a platform issue, but making sure that it's understood that that's a blocking issue is you know what we need to get to foreign.

A

Thanks everybody I'm gonna, stop recording now because I think we're yeah we're at the last minute. Let's see here, we go.