I’ve got a couple of PRs out there now that take care of the vast majority of impacted tests:
https://github.com/jakartaee/platform-tck/pull/1269
https://github.com/jakartaee/platform-tck/pull/1251
If we end up refactoring any of these tests for EE 11 such that my PRs aren’t directly usable, changes like what I’ve done will still be needed in order to eliminate EJB 2.x.
There are still 10-15 apps that need some updates in different parts of the TCK. I can keep taking a look at these when I’m back from vacation in a couple of weeks.
-Brian
From: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Sent: Tuesday, March 12, 2024 3:58 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>; Brian Decker <bmdecker@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [jakartaee-tck-dev] Next TCK call
On Mon, 11 Mar 2024 at 17: 28, Brian Decker via jakartaee-platform-dev <jakartaee-platform-dev@ eclipse. org> wrote: I’m trying to make sure that the community
is aware of the amount of work that will need to happen in the TCK to support
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
I’m trying to make sure that the community is aware of the amount of work that will need to happen in the TCK to support this. There are thousands of non-EJB tests impacted by this,
which I’m (slowly) trying to document in an issue -- https://github.com/jakartaee/platform-tck/issues/1250
Although the EJB 2.x APIs have been “optional” for many releases now, they have been de facto required for the platform because of all of the content that has been in the TCK up
to this point.
I see. That's an enormous amount of technical debt we have there.
Maybe we should try to migrate as many as possible, then remove EJB 2.x and just comment out what fails then? I know it's not the most desirable thing to do, but at some point we have to make a choice given our limited amount of resources.
