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

[Arjan Tijms <arjan.tijms@xxxxxxxxxxx>]

Hi,

> Perhaps the TCK could just create some API jar file based on the next "arquillian phase",

I kinda feel like that phase might be to move or clone the APIs at Jakarta / EE4J and rename it to something boring sounding like "Runtime Controller" or "Server Start/Stop Connector" or something like that. Not these exact names, but something along those lines.

The hype cycle brought Arquillian much attention around 2012, but with that also came much fear. I personally don't understand why we as developers always have so much fear for things, but I personally can't change that. What we can change perhaps is the name, and take away some of that fear with it, hopefully.

Kind regards,

Arjan Tijms

On Tue, 2 May 2023 at 16:27, 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".

-- 
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