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
_______________________________________________