| Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted |
My suggestion is that we engage the Arquillian team here. While Arquillian does have weaknesses, I think adoption into Jakarta EE TCKs should be important enough such that the development team should at least commit to working with us to solve issues together. I imagine you can easily reach that team but if you need help just let me know. No tool is a golden hammer. I don't think we need to adopt Arquillian for every test necessary. However, in cases where it is clearly helpful creating yet another one off solution with likely it's own problems does not make much sense to me - for this project or a given Java EE enterprise application. 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 -------- From: Scott Kurz <skurz@xxxxxxxxxx> Date: 3/18/20 7:58 AM (GMT-05:00) To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx> Subject: Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted Romain, 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 :
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:
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 |