Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] 2021 program goal: reduce hardcoded dependence on a fixed implementation


On 10/28/21 3:03 PM, David Blevins wrote:
We had a goal in our 2021 program plan in the Advance Implementation Neutrality slide to "reduce hardcoded dependence on a fixed implementation."

A key part of that in my mind was to ensure that:

 1. We don't need GlassFish specifically to release the TCK

I recall this goal as well.

 2. People who run the TCK do not need to download and setup GlassFish

For Jakarta EE 9.1, I believe that the only need for a fixed implementation is for running https://download.eclipse.org/jakartaee/xml-web-services/3.0/jakarta-xml-ws-tck-3.0.0.zip but technically that is not a hard requirement (e.g. implementations could in theory run two EE implementations of their choice).  In case its not obvious, the two EE server implementations will make remote web service invocations to each other.  The `ts.jte` configuration settings still refer to one of the those servers as the vendor implementation and the other as the reference implementation.


>From my experience with Jakarta EE 9.1 TCK you still had to download, unpack GlassFish and set GF_HOME for the TCK to function, regardless of what implementation is being tested.

GlassFish includes the Derby database server + JDBC driver which is convenient for testing but if you download Derby separately, you shouldn't need GlassFish anymore for TCK testing.  With the one exception that you need to run two separate EE server instances for running the https://download.eclipse.org/jakartaee/xml-web-services/3.0/jakarta-xml-ws-tck-3.0.0.zip tests.  Just be sure to remove any calls to the `ant start.ri` task.

Please let us know if this is not true, so we can create a tracking issue for eventually resolving that.


Is my observation correct?

I'm not sure.  For WildFly TCK testing, we did remove the ant calls to `start ri` but didn't yet remove all GlassFish references from various class paths in `ts.jte`. 

For EE 10, we are updating the Platform TCK build to make less use of GlassFish (currently changing the build standalone tck script for that).  

Also, as previously discussed, the Platform TCK contains GlassFish deployment descriptors for various tests that likely cannot be removed without impacted other EE implementations.  Since other EE implementations may be using the (2909) GlassFish deployment descriptors. 

I don't think we are in a rush to completely remove GlassFish from the Platform TCK but definitely are progressing forward in doing so.  I am pretty sure that once we have completed refactoring all of the Platform TCK tests, that making changes like (completely) removing a fixed implementation will be easier.

Scott

Back to the top