|
Hi Amelia,
Thank you for the kind words.
Scott and and I talked about setting up a time to chat at some point. Perhaps he and I can discuss the best way to handle this type of info when we connect?
Best
Lance
Hola Lance,
Your vast knowledge on TCK waters is deeply valuable, always. Yet specially more on public threads and discussions like this.
You are amazing and Mark is amazing for using the forum to welcome your feedback!
To all TCK Jakartees,
Where should we be adding the information Lance is providing? What page, wiki...? Lance, do you have a recommendation? Or do you have the bandwidth to submit a PR under the TCK pages? -- brainstorming here.
To properly thank you, we must scale your knowledge! 💪
🤗
API signatures should match exactly what the spec requires nothing more nothing less. Vendors who provide their own API jars, should not include extra Annotations in their API jar for
a Jakarta technology.
We have had similar issues in the past for example where a Java EE licensee added the @Deprecated annotations to a Java EE API which only had the javadoc @deprecated tag causing the signatures to fail.
Best,
Lance
On 17/03/2021 16:29, Lance Andersen wrote:
If compatibility is still of the same importance as it was for Java EE, then there should not be any extra annotations/APIs that are vendor specific that are included within the signatures.
Maybe this is less of a concern now for Jakarta EE, I hope not?
There are annotations, such as this BND annotations, that may be used at build time and have zero impact on runtime behaviour and/or compatibility.
For this specific case, what are your compatibility concerns regarding ignoring the annotation when performing the signature test for the TCK?
Mark
On Mar 17, 2021, at 12:21 PM, Mark Thomas <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>> wrote:
Hi,
I'd like to propose we relax the signature testing for some specific scenarios.
This proposal was triggered by this TCK issue:
https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-tck/issues/643__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbGz9Ya7Xg$
<https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-tck/issues/643__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbGz9Ya7Xg$>
Vendors providing their own API JARs may wish to add annotations such as aQute.bnd.annotation.spi.ServiceConsumer which are required if using BND to generate correct OSGI metadata.
These annotations have no runtime impact and are, effectively, transparent to API clients.
Conversely, it is possible an API project could add such an annotation but a vendor providing their own API does not.
The proposal is that we create a list of annotations that should be ignored when performing the signature tests for the TCK.
The initial list (based on those Tomcat 10 is currently using) of proposed annotations to ignore is:
aQute.bnd.annotation.spi.ServiceConsumer
Annotations would have to be confirmed as having no runtime impact before they could be added to this list.
The alternative approach, in this instance, is to add these annotations to the Jakarta provided API JARs and require any vendor provided API JARs to use the same annotations. However, I suspect that there will be other annotations associated with other build
time tools that will fall into this category over time and that it will not always be appropriate to include the annotation in the Jakarta provided API JARs.
Thoughts?
Mark
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbHJJwrpZA$
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx <mailto:Lance.Andersen@xxxxxxxxxx>
_______________________________________________
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__;!!GqivPVa7Brio!IS3Jb08h9onTHR0W2I-xNMZt8JvX2wxUcWh2UEsINQSbGZKxeCONEtvVdQbBXPV4bA$
_______________________________________________
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__;!!GqivPVa7Brio!IS3Jb08h9onTHR0W2I-xNMZt8JvX2wxUcWh2UEsINQSbGZKxeCONEtvVdQbBXPV4bA$
<oracle_sig_logo.gif>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
|
