Skip to main content

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



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

Back to the top