Consume Jakarta Batch tests from batch-tck rather than duplicating within this project.

[scottkurz]

BASIC BACKGROUND

The Jakarta Batch tests in this repository are rooted off of path: https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/ibm/jbatch/tck.

These essentially duplicate the same exact tests in https://github.com/eclipse-ee4j/batch-tck.
This is a legacy of the way in which the tests were originally provided to CTS.

There may be some differences (I haven't checked recently) related to logging and assertions, but the core batch semantics of the tests are (should be) exactly the same.

It seems like a step forward would be to update the build in this project and pull in the artifacts from the 'batch-tck' maven coordinates, but to otherwise execute the tests, within jakartee-tck automation, in the exact way they're executing now.

ALTERNATIVE

Lurking in the background, there's the idea of making the batch-tck project more flexible and useful, to the point where there's no need to include the batch tests in this jakartee-tck project.

E.g. we talked about some enhancements: https://ondro.inginea.eu/index.php/possible-ways-to-use-arquillian-in-jakarta-ee-tcks/

If that seems like the preferred approach, to decouple from this repo, then well, possibly we should just focus on that.
Although pulling in the tests from batch-tck seems easier if we're at the point where we want to add some new batch tests, and don't want to duplicate.

SOME MORE DETAILS

If we divide up the artifacts into:

1. test classes (with test methods), test utilities
2. batch artifacts (things that directly implement the batch API)

I'd expect 2. to be exactly the same with the differences in 1. (I could be wrong though, if some of the logging diffs are present in 2.).

[scottkurz]

Update: we have gone ahead with a refactor of batch-tck to use JUnit 5 with the possibility of complementing this with an Arquillian extension: https://www.eclipse.org/lists/jakartabatch-dev/msg00199.html

At this point then we should go ahead and remove the batch tests as source in the platform TCK repo, and work on consuming these tests via Maven dependency.

There is also some work needed probably for the tests that require database tables.

These currently require a test execution setup step to run vendor-specific DDLs. We have to decide if this is acceptable and can fit into the platform TCK execution, or, if it is a large burden, I suppose we could consider refactoring this DB creation into test application JPA (but that'd require another separate effort).

[scottmarlow]

@scottkurz is https://github.com/eclipse-ee4j/batch-tck ready to take over running of Jakarta Batch TCK tests for Jakarta EE implementations? If yes, for this issue, could you add a note to https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/user_guides/jakartaee/src/main/jbake/content that explains what Jakarta EE implementations need to do? Perhaps similar to https://eclipse-ee4j.github.io/cdi-tck/#_running_the_tests_in_the_container_core_and_ee_parts

Actually, perhaps adding the note to https://github.com/eclipse-ee4j/batch-tck is better and mention the note link here in this issue.

[scottmarlow]

https://www.eclipse.org/lists/jakartaee-tck-dev/msg01395.html clarifies some possible options for validating the Platform requirements for BATCH.