Andy, it’s exactly what I want – all specs use the same versions of frameworks. We can always upgrade versions by releasing new versions of the parent pom. From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Andy Guibert
Sent: Wednesday, February 5, 2020 10:01 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec Arjan, previously in this thread I proposed that we standardize on JUnit+Arquillian. I think Arquillian is a must-have technology for modern TCKs (and most vendors already have Arquillian impls), and then JUnit is much more widely used than TestNG therefore I think we should prescribe JUnit (but not force existing specs like BVal and CDI to change). Dmitry, I think we should not prescribe a parent pom for TCKs because it will force all TCKs to use the same versions of JUnit and Arquillian. Updating the versions in the future would be essentially impossible because it will be difficult to reliably test the matrix of all specs multiplied by all vendor implementations. As long as we stick to the same technologies across the board, the versions we use are less important (e.g. as a test engineer I don't care if one spec uses Arquillian 1.10 and another spec uses Arquillian 1.11). If I remember well MicroProfile TCKs are not consistent with frameworks they use. Some of them are TestNG, some of them are JUnit. I think we all agree that It’s what we want to avoid. IMO, the best way to accomplish it is to create a TCK parent pom, define all dependencies there and recommend all projects to use it. We can place in the same repository where EE4J parent pom is. -- Dmitry One thing I'd love to see there is a consistent use of the Arquillian container profile, or even have a strong recommendation Arquillian is used. Additionally, though I'm not in any way a fan, all of MP (if I'm not mistaken) as well of CDI, BeanValidation and Batch use TestNG, not Junit. Perhaps it's best to have some consistency there as well. I remember that in Java EE 7 samples we had the door open for "whatever" and essentially every test used another combination of technologies. The permutations must have been a dozen or more. As test engineer it's not unlikely you have to jump between tests for different but related APIs., E.g. for Jakarta Faces I'd jump between Jakarta Servlet, Jakarta _expression_ Language, Jakarta WebSocket, and Jakarta Security. Having to adjust mindset every time would not be productive, especially since often there's no reason for a project to use technology X over technology Y other than that person A just started to use X and not Y. As for the Arquillian and consistent use of profiles; as a Jakarta EE vendor I'd hate to write and maintain adapters and porting kits for every API in Jakarta EE. Ideally I provide 1 implementation to run all of the APIs that make up the full platform. _______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
