[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted
|
I really prefer we not do anything one
off and go the Arquillian approach. The biggest benefit to
maintaining uniformity is that contributors across Jakarta EE
technologies will not need to re-learn the same thing.
The reality also is that Arquillian
remains the de-facto testing solution for Jakarta EE. It is
unfortunately still far from perfect but workable. I would like to
believe we could adopt Arquillian across Jakarta EE and help
smooth out the wrinkles in Arquillian itself in the process.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
On 3/17/2020 2:31 PM, Scott Kurz wrote:
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
--------------------------------------------------------
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev