Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Going through EE8 release using Glassfish TCK jobs
This isn't quite right.

We're updating the APIs in order to update the javadocs.  We need to release those updated API jar files in order to create the combined Jakarta EE API jar file.  Since we're releasing those API jar files, we want some confirmation that they're correct.  Running the TCK against those API jar files gives us that confidence.  Those TCK results don't need to be saved or published since they don't correspond to a complete Compatible Implementation.


Separately, we need a Compatible Implementation for every spec.  That CI does NOT need to use the updated API jar file, although it may.  The release review for each spec needs to point to the CI and the TCK.  The CI needs to pass the TCK and those results need to be made available.

For the platform, the CI will be Eclipse GlassFish 5.1, unchanged.  We will test it with the Jakarta EE platform TCK and make those results available.

For individual specs, there are several approaches:

The CI can be updated to use the updated API jar file, and this updated CI can be tested with the TCK.  In this case, the TCK testing combines the requirement for testing the API jar file with the requirement for testing the CI, and these TCK results would be saved and published.

The CI can be updated without using the updated API jar file, and this updated CI can be tested with the TCK.

The CI that was released along with Eclipse GlassFish 5.1 can be used unchanged, and this pre-existing CI can be tested with the TCK.

Specs with no standalone implementation and that use GlassFish as their implementation can continue to refer to Eclipse GlassFish 5.1, and can test it with the standalone TCK for the spec.

For specs with no standalone TCK, they would use Eclipse GlassFish 5.1 as the CI and would test with the platform TCK using the subset of tests defined for that spec.

Still unclear?


Ed Bratt wrote on 7/17/19 11:36 AM:

My opinion is: The GlassFish binary isn't what needs to be preserved. That isn't being released. It is just a mechanism for running the the TCK. The thing being released is the API JAR. The tests will verify that, when using a CI -- GlassFish 5.1, which is a candidate compatible implementation now (verified by the prospective Jakarta EE TCK in it's original form).

If the component teams had their own customized TCK tasks, they could use those as well.

So -- you start with a CI -- in this case Eclipse GlassFish 5.1.

Into that you generate a trial build, and substitute the release candidate API JAR that you want to validate for compatibility.

You run the TCK tests necessary to validate that API JAR (either stand-alone TCK tests, or CTS TCK if the component doesn't have a standalone TCK).

When you get a PASS result for the API JAR from the TCK, you can make the compatible claim and you have the test result to back it up.

For the cases of components with stand-alone TCKs, the result is much more focused. With the CTS, you will have a bunch of results that don't really matter, to the component you are releasing, but that's just a consequence of the test suite. If the end-result is PASS, that component may be considered compatible.

Again, it is the API JAR that needs to be preserved, along with the test results. That is done, by virtue of staging it to OSSRH, then finally pushing it to Maven Central. The trial build of Eclipse GlassFish isn't released and need not be preserved.

Sure, other forms of testing might be more robust, but we decided that we would allow for this kind of "minimal" validation this time since we did not need, nor did we want to go to the effort required to make another release of Eclipse GlassFish. We could try to preserve the has from GitHub so we could re-create the build. We could preserve a hash of the build itself, but I don't think this is required.

That's my take on this, anyway.

-- Ed


On 7/17/2019 11:25 AM, arjan tijms wrote:
Hi,

On Wed, Jul 17, 2019 at 8:02 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
The issue I don’t see how to address is producing a persistent version of the Glassfish binary with persistent TCK results as we seem to be requiring for spec release reviews.

As for the GlassFish binary, what about providing the location GF was downloaded from (and perhaps a hash of that binary?), and if build from source for some reason, the git revision?

For instance, I've been using the following for the JASPIC TCK run:


And the hash (sha1) "f63f451aa42a85e40a16766487809772ea547653"

Should we provide those details for the results?

Kind regards,
Arjan





 

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

Back to the top