JPA standalone TCK refactor with Junit.

[gurunrao]

JPA standalone TCK refactor with Junit 5.
Current status of test execution with GF 7 Eclipse Link run are Tests run: 2071, Failures: 0, Errors: 1, Skipped: 3

Error test name: com.sun.ts.tests.jpa.se.entityManagerFactory.ClientIT#createEntityManagerFactoryNoBeanValidatorTest

PS: PR doesn't include code changes for Signature tests.
TODO: CI jobs for test run with GF 7 and fix for one test error.

[scottmarlow]

JPA standalone TCK JPA standalone TCK refactor with Junit and Arquillian. Current status of test execution with GF 7 is Tests run: 2071, Failures: 0, Errors: 1, Skipped: 3

@gurunrao previously, the Persistence Providers were able to test without a Jakarta EE application server. Testing Persistence Spec implementations with a Jakarta EE application server introduces additional requirements for the implementations. Having said that, I think this pull request is very good progress forward!

Since you have already started adding EE testing in this pull request, could we just make this effort handle the Full Platform testing? After that is complete, we can consider how to create a Standalone Persistence TCK without EE testing. What do you think? Ping me on slack if you prefer to talk there or we could have a zoom call.

@lukasj do you have anything to add?

[gurunrao]

JPA standalone TCK JPA standalone TCK refactor with Junit and Arquillian. Current status of test execution with GF 7 is Tests run: 2071, Failures: 0, Errors: 1, Skipped: 3

@gurunrao previously, the Persistence Providers were able to test without a Jakarta EE application server. Testing Persistence Spec implementations with a Jakarta EE application server introduces additional requirements for the implementations. Having said that, I think this pull request is very good progress forward!

Since you have already started adding EE testing in this pull request, could we just make this effort handle the Full Platform testing? After that is complete, we can consider how to create a Standalone Persistence TCK without EE testing. What do you think? Ping me on slack if you prefer to talk there or we could have a zoom call.

@lukasj do you have anything to add?

@scottmarlow - The refactored standalone JPA TCK is using GF eclipselink libraries[TCK tests does not run inside the GF container]. The refactored TCK runs in same manner with GF, as EE 10 standalone JPA TCK. The scope of PR is for standalone JPA TCK and not for JPA Platform TCK.
TCK community will have to solve technical debt on TCK vehicles for Platform JPA TCK task.

[scottmarlow]

JPA standalone TCK JPA standalone TCK refactor with Junit and Arquillian. Current status of test execution with GF 7 is Tests run: 2071, Failures: 0, Errors: 1, Skipped: 3

@gurunrao previously, the Persistence Providers were able to test without a Jakarta EE application server. Testing Persistence Spec implementations with a Jakarta EE application server introduces additional requirements for the implementations. Having said that, I think this pull request is very good progress forward!
Since you have already started adding EE testing in this pull request, could we just make this effort handle the Full Platform testing? After that is complete, we can consider how to create a Standalone Persistence TCK without EE testing. What do you think? Ping me on slack if you prefer to talk there or we could have a zoom call.
@lukasj do you have anything to add?

@scottmarlow - The refactored standalone JPA TCK is using GF eclipselink libraries[TCK tests does not run inside the GF container]. The refactored TCK runs in same manner with GF, as EE 10 standalone JPA TCK. The scope of PR is for standalone JPA TCK and not for JPA Platform TCK. TCK community will have to solve technical debt on TCK vehicles for Platform JPA TCK task.

Thanks @gurunrao , I saw EJB beans in the source like jpa/src/main/java/com/sun/ts/tests/jpa/ee/packaging/ejb/descriptor/Stateful3Bean.java which led to me thinking that we were running EE tests inside the GF container but just because the source is there, doesn't make it so. Thanks for pointing this out.

[scottmarlow]

@gurunrao should we merge and continue work on it via separate pull requests after?

[gurunrao]

@gurunrao should we merge and continue work on it via separate pull requests after?

Please note, The JPA Platform TCK has an overlap of tests with Standalone JPA TCK [ there is an overlap of more than 90% of tests], Hence we need to revisit tests covered as part of com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22. when we enable com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests with vehicles, We will revisit com.sun.ts.tests.jpa.ee test at that point in time. I have added basic junit annotation to com.sun.ts.tests.jpa.ee as part of PR to save time in future, since we are blocked due to test vehicles.
For Platform TCK, we need to run com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests in a test vehicle, as you already know that's a blocker for our development at this point in-time.

[Tomas-Kraus]

@gurunrao How long will it take to merge this PR? I'd like to start working on set of tests to validate Jakarta Persistence 3.2 in near future.

[gurunrao]

@gurunrao How long will it take to merge this PR? I'd like to start working on set of tests to validate Jakarta Persistence 3.2 in near future.

Please use master branch since PR needs tobe reviewed and merged by the community. We should sync with tckrefactor the changes made againts master branch post merge of the PR.

[scottmarlow]

@gurunrao should we merge and continue work on it via separate pull requests after?

Please note, The JPA Platform TCK has an overlap of tests with Standalone JPA TCK [ there is an overlap of more than 90% of tests], Hence we need to revisit tests covered as part of com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22. when we enable com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests with vehicles, We will revisit com.sun.ts.tests.jpa.ee test at that point in time. I have added basic junit annotation to com.sun.ts.tests.jpa.ee as part of PR to save time in future, since we are blocked due to test vehicles. For Platform TCK, we need to run com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests in a test vehicle, as you already know that's a blocker for our development at this point in-time.

Regarding jpa tests that need to work with vehicles for deploying on Platform/profile implementations. I am thinking we need to:

1. Refer to https://github.com/jakartaee/platform-tck/blob/tckrefactor/jpa/src/main/java/com/sun/ts/tests/jpa/common/PMClientBase.java#L54 which implements UseEntityManager, UseEntityManagerFactory and PMClientBase also provides the common way for (JPA) Java SE based tests to obtain a resource local (database server based) transaction as well as for EE based tests to obtain a Jakarta Transactions usertransaction/transaction (e.g. BMT/CMT) for running a test. Also refer to https://github.com/jakartaee/platform-tck/blob/tckrefactor/common/src/main/java/com/sun/ts/tests/common/vehicle/ejb3share/UseEntityManager.java + https://github.com/jakartaee/platform-tck/blob/tckrefactor/common/src/main/java/com/sun/ts/tests/common/vehicle/ejb3share/UseEntityManagerFactory.java
2. Provide a refactored equivalent of PMClientBase.java (either as a single class or perhaps via multiple separate classes).
3. Provide a refactored equivalent of UseEntityManager.java + UseEntityManagerFactory.java. Perhaps these could be implemented as functional interfaces and used from Lambda expressions (in tests directly or in shared/common code). These would be used instead of PMClientBase mentioned in step 2 so perhaps step 2 can be ignored.

[gurunrao]

@gurunrao should we merge and continue work on it via separate pull requests after?

Please note, The JPA Platform TCK has an overlap of tests with Standalone JPA TCK [ there is an overlap of more than 90% of tests], Hence we need to revisit tests covered as part of com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22. when we enable com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests with vehicles, We will revisit com.sun.ts.tests.jpa.ee test at that point in time. I have added basic junit annotation to com.sun.ts.tests.jpa.ee as part of PR to save time in future, since we are blocked due to test vehicles. For Platform TCK, we need to run com.sun.ts.tests.jpa.core and com.sun.ts.tests.jpa.jpa22 tests in a test vehicle, as you already know that's a blocker for our development at this point in-time.

Regarding jpa tests that need to work with vehicles for deploying on Platform/profile implementations. I am thinking we need to:

1. Refer to https://github.com/jakartaee/platform-tck/blob/tckrefactor/jpa/src/main/java/com/sun/ts/tests/jpa/common/PMClientBase.java#L54 which `implements UseEntityManager, UseEntityManagerFactory` and PMClientBase also provides the common way for (JPA) Java SE based tests to obtain a resource local (database server based) transaction as well as for EE based tests to obtain a Jakarta Transactions usertransaction/transaction (e.g. BMT/CMT) for running a test.  Also refer to https://github.com/jakartaee/platform-tck/blob/tckrefactor/common/src/main/java/com/sun/ts/tests/common/vehicle/ejb3share/UseEntityManager.java + https://github.com/jakartaee/platform-tck/blob/tckrefactor/common/src/main/java/com/sun/ts/tests/common/vehicle/ejb3share/UseEntityManagerFactory.java

2. Provide a refactored equivalent of PMClientBase.java (either as a single class or perhaps via multiple separate classes).

3. Provide a refactored equivalent of UseEntityManager.java + UseEntityManagerFactory.java.  Perhaps these could be implemented as functional interfaces and used from Lambda expressions (in tests directly or in shared/common code).  These would be used instead of PMClientBase mentioned in step 2 so perhaps step 2 can be ignored.

The vehicles used by JPA tests for Platform TCK are listed in file vehicle.properties [ https://github.com/jakartaee/platform-tck/blob/master/install/jakartaee/other/vehicle.properties#L105 ]. The vehicles will require a generic implementation, to be used by all the modules.

[gurunrao]

@scottmarlow - I am planning to merge the PR[EOD today], since there are no review comments for JPA Standalone Tests refactor.

[scottmarlow]

Thanks @gurunrao for the change!