Re: [jakartabatch-dev] Batch TCK discussion continued - Junit 5, Arquill

[Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>]

Hi all,

Here's my new and improved PR that rebased onto master: https://github.com/eclipse-ee4j/batch-tck/pull/21

It also links to an example project that uses Arquillian to run the TCK against GlassFish, including the EE test.

This solution also solves the problem of packaging. Each implementation can create a project similar to the example GlassFish project, modify the Arquillian plugin which it contains and build any deployment package supported by Arquillian, not only WAR. And implementations that run on a flat classpath can just run without Arquillian. It's also possible to use any other technology instead of Arquillian, e.g. reuse an existing Jakarta EE porting package used in the EE TCK.

As I wrote in the PR, a similar solution can be achieved with Test NG but it requires a bit of a different approach to overcome the limitations of Test NG. I personally prefer JUnit 5 because it's newer, more modern and has a very powerful design. But Test NG has some features that are just coming to JUnit 5 or may not come at all. We can have a separate discussion about that.

Ondro

št 3. 6. 2021 o 16:05 Scott Kurz <skurz@xxxxxxxxxx> napísal(a):

Ondro,

Yes, your solution sounds ideal given that we want to be able to use this one standalone TCK to certify both within and outside of the Jakarta EE Platform.  

Using a single WAR as packaging should be fine in EE (no need to have any finer application scopes).   The platform TCK also at one time exercised the same set of tests in an EJB JAR package;  I'd assume it still does unless there have been changes.

And no need or desire to standardize any other package for non-EE, this hasn't been an issue in the past so just putting it all on the classpath should be fine there.

So thanks again, for rebasing, (and if the reformatting is too painful we can try to standardize that better.)
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

"Ondro Mihályi" ---06/02/2021 01:35:27 PM---Hi, Yes Scott, I will rebase my PR onto master. I just waited until people here

From: "Ondro Mihályi" <ondrej.mihalyi@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 06/02/2021 01:35 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Batch TCK discussion continued - Junit 5, Arquillian, etc.
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>

---

Hi,

Yes Scott, I will rebase my PR onto master. I just waited until people here are interested in such a solution.

To clarify my proposal again and the options we have with TestNG / JUnit 5 / Arquillian

• We could continue with Test NG and just add Arquillian, but it's a cumbersome and JUnit 5 offers more flexibility and a modern toolkit
• We could migrate to JUnit 5 and then just add Arquillian as Arjan suggested, but that would require some standard packaging of the test application like WAR. However, JBatch doesn't require implementations to support WAR so it adds extra burden for them to add an Arquillian extension to repackage the test application. We could also create plain JAR packages but then implementations that require WAR would need to repackage the app
• The solution I propose in [1] allows running the tests with JUnit 5 on the current classpath without Arquillian. To run the the tests inside a container like Jakarta EE server, it provides a stockplugin for Arquillian to package all the classes and resources on the classpath into a WAR. Implementors can add the JUnit 5 Arquillian extension and use our plugin for Arquillian to package the test apps as WARs. But, in theory, they can also use any other mechanism to package the apps and run the test with it, so it's probably even possible to reuse the existing Jakarta EE TCK porting package to deploy the tests on an application server.

Of course, it would be nice to have a standard way to package a test application but even Arquillian doesn't abstract well enough here. It uses Shrinkwrap to create a specific type of archive (WAR or JAR), which might not be suitable for some runtimes.

For Batch we don't even need to have any packaging because it's OK to have everything on the classpath for all tests. It's OK to run the tests with plain JUnit 5 and it's also OK to assemble all classes and resources in a single test app (e.g. WAR) used by all the tests. I demonstrated how to automate the latter for Arquillian with a simple plugin for Arquillian.

I can see that for other specs, it's needed to package only a subset of the classpath for tests. Then it would be nice to have some standard and abstract way to set up the contents of the package, e.g. by some annotations or a simple API. Arquillian or any other test framework could then adopt such an API and use it to package the test application as needed (e.g. as WAR).

But first, I'll follow up with rebasing my PR against the master branch so that we can discuss about it in the PR. When we have a good solution for Batch, we can raise a proposal on the TCK project level and propose it as a standard approach that can be easily adopted by other standalone TCKs.

Ondro

[1] https://github.com/OndroMih/batch-tck/pull/3 


st 2. 6. 2021 o 14:47 Scott Kurz <skurz@xxxxxxxxxx> napísal(a):

So steering back to the Batch TCK, it seems we should move forward with Ondro's:  https://github.com/OndroMih/batch-tck/pull/3 as a next step, converting to JUnit 5.
From there a further step would be to add Arq adapter runners, etc.

Ondro graciously offered to merge on the latest master.   (I know we've reformatted since but without formalizing via checkstyle.)    

(Also I see we don't have a SNAPSHOT version set.. feel free anyone to improve project shortcomings like these).

But if we're good with this as a high level plan, Ondro, can you please do that when you get a chance and reply here with the updated PR for anyone who wants to do a code review?

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

arjan tijms ---05/29/2021 07:23:18 AM---Hi, On Fri, May 28, 2021 at 11:08 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx>

From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 05/29/2021 07:23 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Batch TCK discussion continued - Junit 5, Arquillian, etc.
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>


---




Hi, On Fri, May 28, 2021 at 11:08 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote: This is what arquillian is and it is adopted. Another api wouldnt get as much traction - tomcat wouldnt be under radar for ex - until it is done by
Hi,

On Fri, May 28, 2021 at 11:08 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
This is what arquillian is and it is adopted. Another api wouldnt get as much traction - tomcat wouldnt be under radar for ex - until it is done by the api creator.
So personally i wouldnt invest in it or ewpect vendors to follow and redo arquillian already work so we would end up with another arquillian bridge i think.
Arquillian was bringing a simpler way to write tck tests, a standard arquillian would bring a vendor neutral way, less value IMHO.

Maybe, anyway, I just wanted to put the idea out there. Perhaps, if Red Hat would be open to it, donating Arquillian core (without the forest of extensions) to EE4J and/or the TCK project, might be worth considering.

Kind regards,
Arjan
 _______________________________________________
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_______________________________________________
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