Skip to main content
[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...
Hi Scott, Ed,
I am working on common sources, which will be used by the TCK targeted for separation from Jakarta EE TCK repository, Once completed the common tck artifact will be pushed to maven and can be re-used by tck which is separated/refactored (we will refactor JAXRS 3.1 proof of concept source to have same artifact). We have already added TSURLInterface to be included with common jar/artifact (https://github.com/gurunrao/jakartaee-tck/commit/722f8f679b9cf261999fe9550ce4b647a7d496dc#diff-60098e5a03f994249b8808bd422bddefc01b417fb94bf83ede6d53f57ed94d7c).

regards,
Guru
From: jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> on behalf of Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 27 August 2021 04:54
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>; Scott Marlow <smarlow@xxxxxxxxxx>
Subject: 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$

Back to the top