[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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. 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.
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?
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.
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.
-- 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$