[
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:42 PM, Lance Andersen
wrote:
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?
+1
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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev