Re: [jakartaee-tck-dev] [External] : Re: [data-dev] New Tools and Challe

[Olivier Lamy <olamy@xxxxxxxxxxx>]

On Wed, 3 May 2023 at 12:27 am, David Matejcek <david.matejcek@xxxxxxxxxxx> wrote:

On 02. 05. 23 14:10, Lukas Jungmann wrote:

I may have misunderstood this comment but wiring tests to particular editor sounds wrong to me.

Actually I meant exactly opposite - tests not being dependent even on Maven; and it is also a reason why JEE and all non-jar-file-servers are now considered as obsoleted (and still will be for a long time, but at least we started moving). You cannot simply run and debug tests, you always have to do some additional steps, something fails, then you have to investigate what happened and why, destroy the environment, start again.

Instead of just using the same path which doesn't depend on Maven/Ant/Eclipse/Idea/Netbeans/...

The maven.failsafe.debug doesn't work with "classic" servers (at least not with GlassFish and Payara).

Most of sources are created in editors. But we all are used to start everything from the command line - exactly because of this issue. Not just hitting the play button or "run as" in a context menu. We still live in 2010 or even in earlier times.

In some of previous emails I sent some trivial examples - they can be executed in any editor just like any other standard JUnit5 test. For the TCK we just need to avoid mandatory dependency on GlassFish.

Perhaps the TCK could just create some API jar file based on the next "arquillian phase", so it would be possible some future evolution, switching technologies like Arquillian, Test Containers, or even k8s, bash scripts, etc. However I don't think there is anyone at this point who would be able to transform the current ant-based TCK state to such "shiny new perfect project".

As far I can see, the tckrefactor branch has already started this migration path.

And a few TCK suites have already been migrated.

That’s why I don’t understand this “anyone ….”?

To be honest we need something both runnable easily in IDE and via a build tool such Maven so we can run TCK in an automatic way such as CI server to validate changes etc..

As said in a previous email, if using an Arquillian embedded implementation everything is running very easily within IDE and Maven.

Currently at least with Jetty, I can modify TCK servlet sources, Jetty sources and then run everything within an IDE without additional steps. 

And then once done pushing it to validate the full suite with the help of a Maven build.

As long as you have an embedded Arquillian impl it's all nice and easy.

Whereas something such Testcontainers will add a lot of additional steps such rebuilding the servlet container, rebuilding the image and restarting it.

This is probably what is happening today for only remote Arquillian impl. And I can understand the frustration but nothing related to Arquillian.

But TBH I have no idea how difficult it would be to have an Arquillian embedded for Glassfish but this could help.

-- 
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev