Currently it is not possible to use JavaFX in OpenLiberty (a Java EE 7 compliant app server), so by requiring JavaFX support in the BeanVal 2.0 TCK, we are effectively requiring to add JavaFX support for Java EE 8 (since Java EE8 includes BeanVal 2.0).

I've spent several hours trying to get this to work, and a proper solution is going to require me to mock up a server-side feature that provides JavaFX API to the server runtime, since OpenLiberty uses an OSGi-based server runtime with a strict classloader separation between the server runtime classloaders and application classloaders, so simply sticking jfxrt.jar in the test app is not sufficient.

I would be more willing to jump through hoops if OpenLiberty users could actually leverage JavaFX in their applications somehow, but going through all of this effort just to pass this section of the TCK seems unreasonable.

Perhaps we can have a separate profile for Java EE certification of the BeanValidation 2.0 spec? I propose that we simply exclude the JavaFX tests for the existing "incontainer" profile.