| Re: [jakartabatch-dev] TCK directions / form factor , e.g. Arquillian - opinions wanted |
Thanks Romain for these points, replies:
> From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
> Hi Scott,
>
> Hmm, there are also cons with Arquillian:
>
> 1. requires an integration (only always there for EE servers)
I'm noticing Yasson (https://github.com/eclipse-ee4j/yasson/blob/master/yasson-tck/pom.xml) uses the
https://github.com/arquillian/arquillian-container-weld container.
Could this be a good fit for Batch, since a batch implementation would want CDI function as well?
I'm thinking this is what the Batch "SE" path could look like, (though I admit, I might be missing something).
> 2. execution and accuracy highly depend on the adapter (bval and cdi
> proved that, several TCK runs are done in fake env cause of
> Arquillian @Deployment model),
This sounds important but I'm not sure what you're saying. Any reference you could point to to help us understand the details?
> 3. each class must be isolated somehow (which can be a pro since
> each test can be a different app but is also a cons since some runs
> can be unexpected as in 4.),
> 4. deployment is part of the test definition (so SPI and friends
> require some custom integration anyway)
Good points, let me expand on my thoughts.
Right now the Batch TCK gets zipped up in one big WAR, with all batch Java artifacts and job XML. I was wondering if we could, as a shortcut at least, start by keeping things in one big ShrinkWrap WAR... even if we have to smash some classes together.
I'm not sure if that makes sense, but I'm agreeing that breaking apart the test application artifacts, and re-packaging them one test class at a time, would indeed be a bit painful ! There is some reuse of artifacts across more than one test. So I don't know, maybe smashing things together could be ugly in some ways, but I do recognize the pain of newer, fine-grained packaging.
> Personally I think the SE part should stay SE since it does not need
> arquillian and it is trivial to extend arquillian to deploy the tck
> in a war if you want to run them anyway - without modifying any test class.
> The EE part follows the same philosophy IMO even if it would be more
> convenient to have arquillian tests but I would rather try to stay
> aligned with most EE tests so if TCK are not massively migrated I
> would keep it like that otherwise I would move to arquillian for EE
> tests only.
>
> Romain Manni-Bucau
It sounds like you're suggesting to stay with what we've got but to add a WAR wrapper around it so we can execute it in EE, within an app server?
That would be convenient, e.g. for the batch impl in Open Liberty which can't easily be extracted and run in SE mode (a lot easier than setting up to run just the Batch portion of the Jakarta platform TCK).
But since the platform TCK wouldn't just "consume" this WAR, it would still leave us with the problem of duplicating tests, as well as restricting ourselves to assertion/logging/reporting approaches that work in the Jakarta platform TCK environment.
Scott Kurz