Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted

So one suggestion in the https://github.com/eclipse-ee4j/batch-api/wiki/Ways-To-Contribute was the idea that we could/should convert the TCK to Arquillian (like the JSON-B TCK did).
Let me just back up and walk through my thought process, since I know there was no discussion about that.

And I'd like to solicit opinions about what to do
-----

So right now, we have our tests duplicated across both:
- our individual TCK repo: https://github.com/eclipse-ee4j/batch-tck/ This runs test in an SE, non-"app server" environment.
- the platform TCK repo:
https://github.com/eclipse-ee4j/jakartaee-tck/ Runs tests in an EE, "app server" env.

Obviously we want to source from a single place. Still, we're not forced to use Arquillian, we could do our own thing here..

We could explore:
1. Integrating differently, better with the https://github.com/eclipse-ee4j/jakartaee-tck/ project
2. building our own, custom EE standalone TCK

The problems I see with 1.):
- there's a learning curve with the jakartaee-tck as it's its own, custom, kind of complex thing
- how do we keep our "SE" form factor? Not all impls can/will leverage this but some may find it quicker and advantageous to execute tests in this "mode". For batch 1.0 we actually did an Ant transform (find/replace), which seems kind of primitive.

As far as 2., well, it wouldn't be too hard to have a second project take all the test classes, packaging them in a WAR, and putting some sort of JUnit and/or Test NG suite, "wrapping" them.
That would preserve the existing SE mode, and enable an EE mode that avoids the jakartaee-tck complexities.

But from the overall platform perspective, there's value in keeping things simpler and having a smaller number of different directions among the individual component projects. It makes it that much easier to certify against the whole platform.

So if we take for granted that the JSON-B, and beanValidation TCKs have proven the concept of and provided a pattern for a relatively simple Arquillian-based TCK, and that it faciliates SE, non-app server execution mode (which I admit I haven't looked into in detail, not being too familiar w/ Arquillian), then, rather than going off in a new direction (that we don't have yet), I'd like to try to follow these TCKs, and make a second group or pattern of Jakarta TCKs using Arquillian.

Any thoughts? Things I'm missing?

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------


Back to the top