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 29. 04. 23 21:32, Lenny Primak wrote:
 Arquillian is definitely not legacy. There is so much functionality there besides start/stop the server (test enrichment, Arquilian Drone / Selenium) and many more.
I see it as a way to greatly reduce / eliminate boilerplate and eliminate the need for docker at all in most cases.

Activity on TC:

https://github.com/testcontainers/testcontainers-java/pulse/monthly
https://github.com/testcontainers/testcontainers-java/graphs/contributors
https://github.com/testcontainers/testcontainers-java/graphs/code-frequency

https://github.com/testcontainers/testcontainers-java/issues/970

Read the discussion. Actually this issue doesn't break anything, it is just annoying. But the truth is that they promised me the release of TC 2.0 without junit4 dependency some 2-3 years ago, perhaps I should remind them :-)

Activity on Arquillian:

https://github.com/arquillian/arquillian-core/pulse/monthly
https://github.com/arquillian/arquillian-core/graphs/contributors
https://github.com/arquillian/arquillian-core/graphs/code-frequency

Based on this, Arquillian is not just legacy, it is dying, despite me, you, Ondro, Arjan and others contributed to it in last years.
Btw it depends on JUnit4 in tests too. At least it doesn't bring them as a runtime dependency.

That's why I asked if Eclipse would adopt Arquillian or we just plan to take the dying horse for races.

This is more serious issue than the annoying junit4 in dependencies:
https://github.com/arquillian/arquillian-core/issues/444



As for “arquillian test is not a real web app” argument, I use this to make sure the webapp is absolutely “real":

WebArchive archive = ShrinkWrap.create(MavenImporter.class, archiveName) .loadPomFromFile("pom.xml").importBuildOutput() .as(WebArchive.class);

I think more time should be devoted to maintaining / enhancing Arquillian instead of “relegating” it to legacy.

TC is not perfect as well, a critical bug has not been fixed in years, for example, this issue has been around since 2018:


On Apr 29, 2023, at 6:15 AM, 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,
_______________________________________________
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,
_______________________________________________
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,
_______________________________________________
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


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



-- 
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx

Back to the top