Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian -

[Romain Manni-Bucau <rmannibucau@xxxxxxxxx>]

Hmm, think I see reality differently Reza, let me expand why:

1. Arquillian was de facto standard for EE testing something like 5-7 years ago but it kind of shut down. Today it is poorly maintained and the junit 5 big bang helped a lot to make it abandonned by users. All vendors also slowly move to it.

2. EE tck never fully migrated to arquillian except bval, cdi and a few others. Most of the dozens of thousands tests are still "ee custom".

The strength of arquillian is no more its ecosystem - which is often inconsistent and not well compatible - or test facing api but its container abstraction only - and this is usable standalone. We could envision to use it directly but it brings very few for JBatch and most important point for me is to stay smooth for ee consumers. If they want to consume tck they will mainly integrate jakarta tck so better to not force to do an arquillian solution which is often broken in embedded/standalone mode (currznt way to deploy, even EE).

@Scott: I was thinking to this kind of config https://github.com/apache/openwebbeans/blob/master/webbeans-arquillian/owb-arquillian-standalone/src/main/java/org/apache/webbeans/arquillian/standalone/OwbStandaloneConfiguration.java#L37 which makes arquillian vs normal runs different.

JSON-P/B tck - for ex - had the advantage to have a process per test and just require to have the impl in the classpath so execution was representative even in standalone.

Now back to JBatch, what do we need?

CDI? Be able to have a CDI container with some beans and not some other? SeContainer is about that and is trivially backable by arquillian container impl if *some vendors* want. Same applies for the "auto war deployment", vendors can do it with arquillian just implementing a custom deployer filtering the classpath from their client libs.

So at the end I think JBatch should stay standalone and CDI centric, even for its tests.

Le mer. 18 mars 2020 à 05:00, Reza Rahman <reza_rahman@xxxxxxxxx> a écrit :

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

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