Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer
I missed to comment something,

On Fri, Apr 28, 2023 at 7:37 AM Olivier Lamy <olamy@xxxxxxxxxxx> wrote:


On Fri, Apr 28, 2023 at 7:24 AM David Matejcek <david.matejcek@xxxxxxxxxxx> wrote:
On 27. 04. 23 23:06, Olivier Lamy wrote:
Hi,
I Agree too for those same reasons.
We already have a standard way to deploy to containers via Arquillian suite.
Let's not reinvent the wheel :)
And I'm using testcontainer a lot but in this particular case I definitely agree with all the reasons above.
At the end of the day, testcontainer can still be used by the Arquillian container impl? (just write an Arquillian GF using testcontainer)
I already had this, quite easy.

So let's use it?
 
If I look at the case of Servlet TCK with Jetty, this will be a loss of productivity and speed.
Because the Aquillian Jetty is using an embedded Jetty which means it's only one jvm start (e.g everything runs within the same jvm) and it means I can start/debug the tests with IntelliJ very easily.
Using a tool such testcontainer will make this more complicated to debug with a remote started container.

It is not so bad, you just map the port to a concrete value, set this in Eclipse and hit debug. (project - random with most of dependencies, so I can see sources).

Yeah, with Jetty it is much easier, I don't need any settings (if I am not using a different debug port). I can do that even with TestContainers, if I would use 9009 and had it free on localhost.


This step is not the problem but all the steps before reaching this point are the problems and will slow down containers developers with Arquillian embedded support :( 
Because every single line of code change in your container in my case Jetty will mean rebuilding completely Jetty and then rebuilding the Docker images. 
And I guess this will be similar for all implementations...

Whereas with current Arquillian embedded support, after a change in Jetty, we just hit the run button from the IDE and it works.
Maybe if GF had Arquillian embedded support you would understand how it is fast, convenient and super productive :) 
 



This is not the main issue. As mentioned in this thread, every single container will have a different way/need of configuration.
And I guess we don't want the TCK code to be dependent on any specific container.
Arquillian already solves that and btw fix your problem about using testcontainer because you have an implementation for this.
Do we really want to reinvent the wheel with another layer between your test and the container?
As you have some concerns about XML. 
Maybe Arquillian could have some enhancements for sure to support some other formats (but frankly I find that cosmetic but let's not start another discussion about xml vs json vs yaml)
Why not do that and improve it? 
 

-- 
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx





On Fri, Apr 28, 2023 at 6:46 AM Kyle Aure <kylejaure@xxxxxxxxx> wrote:
Hello All,

I am hesitant to agree with this direction.  

I've heard many times that Arquillian is old and not "modern" but it's more modern than the Vehicle approach of the current platform TCK.
Additionally, Arquillian has already solved many of the roadblocks in place when writing tests that need to run on a Jakarta EE platform.

I've used TestContainers extensively and here are the roadblocks that Arquillian has solved that we'd have to solve if we decided to switch to TestContainers:
  1. TestContainers doesn't have a standard Interface for application server containers.
    • We would have to create one, and every Jakarta EE platform would need to implement it (similar to how every platform server has an Arquillian implementation).
  2. We would have to create a library similar to ShrinkWrap that would allow us to programmatically create applications and deploy them to the test container.
  3. We would have to create a set of protocol libraries that also get deployed to the test container so that tests only have to be written once but can be tested either using:
    • Core profile: using REST
    • Web profile: using Servlet
  4. We would have to figure out a way to distinguish between tests that need to run on the client system vs. inside the container.
  5. We would have to create a deployment library that can be extended by those running the TCK to allow for one-off customizations to the application before it is deployed.
    • For example, the Concurrency TCK allows vendors to add custom *-ejb-jar.xml files to artifacts before they are deployed.
  6. Finally, all of this would need to be worked both into the Junit5 lifecycle and the TestContainer lifecycle.
I honestly think the work I've done on the Jakarta Data TCK shows how simple using Arquillian can be and I even had to figure out a way to make that TCK run both in a Standalone mode and on different Jakarta EE profiles (core / web).
I don't think it is feasible to make the jump from Vehicles to TestContainers for Jakarta EE 11.
I also worry that using TestContainers will raise the complexity of running the TCK for vendors as opposed to Arquillian.

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


--
Olivier

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

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


--
Olivier


--
Olivier

Back to the top