Re: [jakartaee-tck-dev] A quick thought about signature tests

[Scott Stark <starksm64@xxxxxxxxx>]

Yes, the sig tests would be about verifying the apis used in an implementation. We have in the past created jboss specific versions of the api jars for various reasons, so being able to verify them is still important.

In going through the CDI tck use of the signature test I noticed that the docs on using the sigtestdev.jar directly were quite out of date with respect to the current sigtest openjdk project status, and that the simplest way is to use the tool was the org.netbeans.tools:sigtest-maven-plugin plugin. There is an outstanding issue on updating the openjdk version: https://github.com/eclipse-ee4j/jakartaee-tck/issues/156

Does it make sense to just adopt the netbeans tools or fork it into jakarta? A github version of that plugin is available here: https://github.com/emilianbold/netbeans-apitest

On Wed, May 27, 2020 at 1:00 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:

I agree that the signature tests still provide a useful cross-check that no accidental (or intentional) changes were done to the API as defined by the Specification.

I don't think the existence of the signature tests prevents individual Specifications from versioning their APIs in between Platform releases.  For example, after we release Jakarta EE 9, JAX-RS 3.1 or Servlet 5.1 are welcome to introduce updated Specifications with respective APIs, TCKs, and Compatible Implementations.  If a vendor's Jakarta EE 9 compatible offering wishes to support these type of updated Specifications in between major Platform releases, then the configuration and compatibility testing of these configurations is an exercise for the vendor.  Since Jakarta EE 9 is defined to include JAX-RS 3.0 and Servlet 5.0, then that combination would still need to be configurable and testable to continue to claim Jakarta EE 9 compliance.  If the vendor also wants to claim support for JAX-RS 3.1 and Servlet 5.1, those configurations would need to be tested separately.  There is also a question about how well do JAX-RS 3.1 and Servlet 5.1 play with the rest of the Jakarta EE 9 platform, but now we're getting beyond your original scenario...

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Mark Thomas <markt@xxxxxxxxxx>
To:        jakartaee-tck-dev@xxxxxxxxxxx
Date:        05/27/2020 12:25
Subject:        [EXTERNAL] Re: [jakartaee-tck-dev] A quick thought about signature tests
Sent by:        jakartaee-tck-dev-bounces@xxxxxxxxxxx

---

On 27/05/2020 14:30, Jan Supol wrote:
> Hi,
>
> I just hit a side-effect I have not thought about earlier, which I want
> to bring to a discussion about the idea of removing/replacing signature
> tests. I am not sure whether it is supports the idea of having the
> signature tests removed or contrary...
>
> The idea I heard quite some time ago, and it may not be valid any
> longer, is that the signature tests are no longer needed, since the API
> is brought over from maven central and noone is modifying the API any
> longer.

That is not the case.

Apache Tomcat continues to provide ALv2 licensed API JARs for a number
of the Jakarta EE specifications and will almost certainly continue to
do so.

The reasons for doing this have varied over time but the amount to
providing the project with greater flexibility for minimal effort. For
example, a local copy of the spec APIs has proved useful when
investigating potential new features such as the HttpServletMapping
interface added in Servlet 4. Having to round-trip via an upstream spec
project would have slowed things down significantly.

The signature tests are also a useful cross-check that the API hasn't
been accidentally modified.

When the API is updated the separate update to the signature files is a
useful cross-check that only the intended changes have been made.

Mark
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev




_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev