[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Relaxing signature testing
|
On 3/17/21 1:29 PM, Amelia Eiras wrote:
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.
The wiki is probably the best location as we didn't transition to
github pages (at least not yet due to other priorities).
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$
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