Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 3/18/20 7:58 AM (GMT-05:00)
Subject: Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted
Romain,
Forgive me if I repeat myself, it's not to drown out your argument, but to say it differently to try to understand.
...
So backing up, in suggesting Arquillian, I have in mind a developer new to the Jakarta Batch. Maybe they ask a question about some behavior on the mailing list, we discuss, and then say, "we should add a TCK test to clarify, would you like to volunteer to write that test?".
At this point, it's too much of a hurdle to expect that they learn the details of the Jakarta EE platform TCK in order to verify their test. Arquillian, even with its flaws, is something that's out there that they can find examples of, and, IIUC, there are existing "adapters" (I'm not using correct terminology) for app server products and also SE+CDI "mode",
Now, if the flaws are great enough, and you're raising some concerns, this is a moot point because Arquillian just doesn't "work" correctly. But trying to understand where the trouble lies... people use Arquillian... I would say the Batch TCK is relatively simple, deploy once, run, assert/validate. Sure we have some timing issues and we poll a lot but I see that would apply in any solution.
Yes, to the person with the role of certifying the entire app server against the entire platform TCK, we have potentially added more work. By pulling Batch out of the Jakarta EE platform TCK, we've created one more "special" TCK ("standalone" if that term isn't too confusing/overloaded). But I'm OK with that because: 1) This is a more specialized role.. not too many people will do this, maybe one per product.. and this person already may have to deal with some quirks of each API within the platform TCK 2) We're not branching out in 20 different directions, just two: Arquillian vs. Jakarta TCK...hopefully there's some commonality / reuse among the set of Arquillian TCKs.
---
That all said, I don't think I really understand what you're proposing though.
If I had to guess, I'd say you are proposing that we continue to develop in duplicate for both the platform TCK https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/ibm/jbatch/tck
and our individual TCK: https://github.com/eclipse-ee4j/batch-tck/ and we look to use ideas like the 'owb-arquillian-standalone' to allow our individual TCK to run in more of an EE environment, for impls that find that convenient?
If so, my objection is that we have to make source updates twice, plus the ultimate validation of these updates requires working with the complicated Jakarta EE platform TCK.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
Romain Manni-Bucau ---03/18/2020 02:45:30 AM---Hmm, think I see reality differently Reza, let me expand why: 1. Arquillian was de facto standard fo
From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 03/18/2020 02:45 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx
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:
_______________________________________________
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
_______________________________________________