Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-spec-project-leads] [jakartaee-tck-dev] [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer

My context: I want to write a TCK test for specs related to the persistence layer. I believe that we need to follow some similarities from the JPA one, which does not use Arquillian.


Question:

  • Is there any plan to move the JPA to use Arquillian? It would be fantastic if JPA, NoSQL, and Data specs followed some guidance.
  • Is there any guide to help a new TCK explore Arquillian, such as the most straightforward way, without thousand of XML and Java, to write a single test?
  • Is there any TCK guidance on new specs?

On Sat, Apr 29, 2023 at 12:15 PM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi,

In its simplest form, which I think is the only form the TCKs should use, Arquillian is used just to start and stop a server, and to deploy and undeploy the war file that the test module created. The Faces and Security TCKs use it like that.

I don't quite get the argument about Arquillian being legacy in that sense. Why is starting a server and deploying an archive legacy? In order to perform a test, most servers save from the embedded ones need to be started. And even with embedded servers the test archive needs to be deployed / associated with the runtime.

Kind regards,
Arjan Tijms




On Fri, 28 Apr 2023 at 23:19, Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
Thank you, the JPA TCK might be the best reference for us.

On Fri, Apr 28, 2023 at 7:54 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Fri, Apr 28, 2023 at 12:57 AM Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
Thank you Scott.

Could someone share the JPA TCK?

The last released (for Jakarta EE 10) Persistence/JPA TCK can be downloaded via https://download.eclipse.org/jakartaee/persistence/3.1/jakarta-persistence-tck-3.1.2.zip which is also referred as the Standalone Persistence TCK.  For this TCK, "Standalone" means the TCKs only dependencies are to have a Persistence Provider implementation that includes the Persistence 3.1 SPEC API and Java SE 11/17.

The source for ^ is in the Platform TCK 10.0.x branch https://github.com/jakartaee/platform-tck/tree/10.0.x.

For EE 11, the source is in https://github.com/jakartaee/platform-tck/tree/tckrefactor but the Persistence tests have not been rewritten yet to work with JUnit/Arquillian (note that Arquillian wouldn't be needed for building the equivalent of the Standalone TCK but would be for the equivalent of the Platform TCK tests for Persistence).

Scott



On Thu, Apr 27, 2023 at 7:03 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
This discussion needs to loop in the jarkataee-tck-dev list as well since component TCKs should be composable into the profile and platform TCKs as well.

On Apr 27, 2023 at 11:57:55 AM, Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:

Dear Jakarta Spec Leads,


I hope this email finds you well. I am writing to discuss the challenges we are facing while creating modern TCK on the persistence layer and to introduce some new tools that could help us overcome these challenges.


Currently, most Jakarta EE specs use the Arquillian framework as the core of the TCK. However, we have found that it can be challenging to work with, especially for newer developers, and it does not work smoothly on modern IDEs such as IntelliJ. Furthermore, the getting started documentation for Arquillian references Java EE 7, a ten-year-old version, and aligns differently from the current Jakarta EE version 10.


Therefore, we believe the Arquillian framework only makes sense for legacy projects. We must explore new options to create a more developer-friendly TCK for modern projects.


We are considering using JUnit Jupiter with TestContainer as an alternative to Arquillian. We believe this approach could simplify the testing process and make it more accessible to new developers. Additionally, we aim to create an easy-to-integrate, contribute, and extensible TCK that can be used for both Jakarta NoSQL and Data specifications.


We would appreciate your thoughts and suggestions on this matter, especially regarding the new TCKs we are developing. We want to ensure that our approach remains neutral to both specifications. We are open to exploring other frameworks that could inspire our work, such as Weld-testing, TestContainer, and JUnit 5.


Thank you for your time and consideration. We look forward to hearing from you soon.



--

Thanks a lot,

Twitter | Linkedin | Youtube

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


--

Thanks a lot,

Twitter | Linkedin | Youtube

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


--

Thanks a lot,

Twitter | Linkedin | Youtube

_______________________________________________
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-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads


--

Thanks a lot,

Twitter | Linkedin | Youtube

Back to the top