| Re: [jakartaee-tck-dev] [External] : EE 10 + brainstorming on what to do with the TCK Porting kit interfaces like TSURLInterface... |
Scott,
I suspect RESTful Web Services won't be the only component that needs this interface. I think I'd pursue the notion of gathering these up into a common artifact that all the separated TCKs can use.
This seems fine to start,
A small point is that it is best to produce separate artifacts
for each of the different types of codes. For example, we likely
need a separate artifact for each folder under
https://github.com/eclipse-ee4j/jakartaee-tck/tree/tckrefactor/src/com/sun/ts/lib.
There could be some common artifacts that do have a bigger
collection of code but best to keep TCK artifacts as small as
possible.
If that seems reasonable, it would seem like keeping it under the purview of the Platform Spec would make sense to me. The mere act of creating a separate JAR artifact doesn't, I don't think, force an additional ballot. That would only be the case if we were going to create this as a separate specification.
Thanks for pointing this out!
I would be curious how do BV and CDI handle things like this? I know that we have porting kits for running those TCKs against GlassFish. Do they have their own porting kit APIs, or do they use the APIs from the Platform?
https://github.com/jboss/jboss-test-audit is an example of what
CDI-TCK is using for expressing and documenting test assertions.
The CDI-TCK also has its own code for whatever it needs to do, it
does not depend on the Platform TCK TCK APIs (CDI + BV opened
sourced their TCKs years ago before the Platform TCK was OSS).
FWIW, the GlassFish porting kits were historically included with the Platform TCK to facilitate delivering them to Java EE licensees. Licensees could refer to them (perhaps port them) to run the TCKs against their implementations. In the current environment, I can't think of a reason these could not be re-homed with the GlassFish project though the core APIs, in my opinion, should remain with the Platform project.
Agreed that the porting APIs still belong in the Platform TCK and
should be available via a Maven artifact, like groupid=jakartatck,
artifactid=porting, version=? (e.g. jakartatck:porting:1.0). Or
whatever we end up using
(https://github.com/eclipse-ee4j/jakartaee-tck/pull/735/files#diff-303ca660733285a7d7848ce1ddf0b6e9d3d152e3decef2d1299560702aec4e89R31
is a draft pr that uses this using our `refactor` branch that we
are doing Platform TCK EE 10 refactoring on).
Also, while we have been working on the PoC, I don't think the Platform TCK is going away anytime soon -- certainly not before EE 10 is finished.
+1
-- Ed
On 8/26/2021 12:56 PM, Scott Marlow wrote:
Issue 737 [1] is for eliminating the Platform TCK interfaces [2] or replacing them with a different mechanism that doesn't require the Platform TCK porting kit interfaces [2]. The JAX-RS 3.1 TCK proof of concept effort [3] is currently including its own copy of the TSURLInterface interface (+ SunRIURL [4]) .
If we do need to publish a common Platform TCK Porting kit artifact, that would need to go through its own release ballot so we need to identify if we really need to accomplish that or if its better to eliminate the Platform TCK porting interfaces.
One idea is to publish extensible TCK porting implementation classes that EE implementations could override via system properties defined on the maven command line.
Other suggestions?
Scott
[1] https://github.com/eclipse-ee4j/jakartaee-tck/issues/737
[2] https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/lib/porting
[3] https://github.com/eclipse-ee4j/jaxrs-api/pull/1002#issuecomment-906644933
[4] https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/lib/implementation/sun/common/SunRIURL.java
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!ZxgjDrmiqsk4IdR5k2AuhskFtOr-vBXsij5ywrbQrXuop31AtnHUQdO4NKbbPqM$