Re: [jakartaee-platform-dev] [DISCUSS] Strategy for putting Web Profile

[Jan Westerkamp <jan.westerkamp@xxxxxxx>]

Hi,

the idea of this discussion point was a little bit different:

Where we are:
We have a lack of resources on the Platform TCK team to do the refactoring of it. A lot of EJB AppClient tests need sometimes time consuming manual rework.
EJB AppClient is in use for testing this part of EJB itself, but it is in use to do integration testing of other Component Specs like Jakarta Persistence.

Currently we do a separate Core Profile release to make and show progress.

Why not do a separate Web Profile release sooner than the Platform (aka Full Profile) release for Jakarta EE 11, as we will do for the Core Profile?

Benefit would be having a focus on the failing test relevant for the Web Profile Component Specs and it's integrations - which should be a subset of the issues.
We would also gaining some time for the TCK team and hopefully the involved Platform (aka Full Profile) relevant Component Spec teams to fix AppClient test issues.

EJB AppClient functionality should not be part of the Web Profile, where EJB Lite is required only.

EJB AppClient Component Spec tests need then to be passed on the Platform release only. This category of tests should have direct or transitive dependencies to lower waves (layers), that are API or Spec dependencies already - not creating additionally dependencies (that could lead to circular dependencies too).

Integration tests not falling into the category above need to be part of the Platform (aka Full Profile) TCK, but not the Web Profile subset.

Component Spec tests and integration tests, that are required to validate non-AppClient technology need to be refactored to not make any use of AppClient itself.

The Platform TCK CI/CD pipelines need to be refactored to support separate releases of all profiles (Core Profile, Web Profile and Platform).

With this approach, we can move hopefully most of these tests with issues into the Platform section and gain time to solve the issues there or decide later, how to proceed with them without blocking a Jakarta EE 11 Web Profile release.

The refactoring of the Platform TCK CI/CD pipelines is a requirement anyway in my opinion to be able to do independent releases - and hopefully other experts of the Platform TCK team than the ones trying to fix the tests (our bottleneck) could take care of it, so we have a better allocation of resources there.

So the difficult part is limited to the required Component Spec and integration tests, that validates required aspects of non-AppClient technologies - required Jakarta Persistence tests might fall into this category - but maybe not all of them - and need to be refactored. But hopefully this is a small subset of all the open test issues we can give priority.

I think we need to get rid of this technical dept to be able to do reliable releases. Finishing the Platform TCK refactoring is important for Jakarta EE 11, so we are able set a requirement to move tests of Component Spec technology to the Component Spec TCK itself and to keep integration testing beyond that on the Platform TCK only for Jakarta 12. Another postponing of this will create similar issues on Jakarta EE 12+ otherwise.
When tests being moved to the Component Spec, the Component Spec team becomes responsible for them and they are tested earlier in the release cycle - which will help to speed up too. 

By the way, when we would mark the AppClient as deprecated, we need to refactor (all) the test anyway to be able to removing them in a future release.

Best,

Jan

Am 27.11.24 um 00:06 schrieb Arjan Tijms via jakartaee-platform-dev:

Hi,

+1 for at least dropping the app client tests as in the proposal.

I'd like to reiterate that there is a potential BIG COST to continuing on the current path. We still don't really have an idea how much more time it will still take to get all partially refactored tests up and running again. After every mountain there may be another mountain. 

I heard someone saying on the call that if we can release in late January or so with all tests passing that would be better.

But nobody ever said we'll have everything done in January. There's nearly zero guarantee for that. It might as well be September 2025 or even later before we pass everything.

So to me the question is more:

"Do you want us to be more than a full year(!) behind our own schedule and behind specifically Spring, just to get some obscure tests to pass for a technology almost nobody ever used and certainly will not ever use in the future?"

Kind regards,

Arjan Tijms

On Tue, 26 Nov 2024 at 18:27, Ed Burns via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Greetings Programs,

At the 2024-11-26 Platform Project call, an idea was surfaced, I think originally by Emily, to separate the ballot submissions of Web Profile from Platform Profile. This thread is intended to discuss and determine the feasibility of this idea.

First, there were at least two questions in the Platform Project call that need answers right away:

• Would this idea help solve the problem of not having to exclude many tests?
• Consider this statement from the Platform Project agenda:
  Scott clarified that the “appclient” tests in question aren’t actually testing App Client itself, but use app client to call EJBs where (some of) the JPA tests are run.
• Q.1: Given this fact, does the Web Profile TCK include tests that use application client technology? If the answer is yes, this idea is moot.
• Q.2: How tightly coupled are the Web Profile and Platform Profile TCKs?
• Can they even be run independently?
• How much complexity would we be introducing by separating them?

Second I want to state some facts about the relationship between application client and the Web Profile and Platform Profile specifications:

• Application Client is only mentioned twice in the Web Profile specification, in section "2.10.1. Bean archive with EJB Session Beans":
• When determining which archives are bean archives, the container must also consider:
• EJB jars or application client jars
• 
  
• The WEB-INF/classes directory of a war
• 
  
• The container is not required to support application client jar bean archives.
• Application Client has an entire chapter in the Platform Profile specification, chapter 10. Overall, there are 188 mentions of application client in the Platform Profile specification.
• Application Client is not even a factor in the Web Profile.

Given that there is no TCK call tomorrow, 2024-11-27, and no Platform Project call next week, 2024-12-03, this [DISCUSS] thread is very important to progress. I look for responses from Guru, Scott Marlow, Emily, Jan, and anyone else who joined the discussion about this in the meeting.

Thanks,

Ed

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev