[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] Issue for call tomorrow
|
On 1/26/22 12:47 PM, Emily Jiang via jakartaee-platform-dev wrote:
Why can't TCKs adopt the same process as the APIs? As long as we prove
the RC is the same as the final staging artifact, we are all good. This
is what I suggested:
Raise a RC for both APIs and TCKs - let compatible implementation to
ratify the artifacts with CCRs
Stage final APIs and TCKs - ballot open with the above CCRs to vote the
staged artifacts.
I think the current process of staging TCK final is ok because TCKs and
specs are in separate repos.
not true; there are some repos hosting both - the API as well as TCK
(and spec document). This is unlikely to change unless there's an
explicit request for it (read as "it is required to do so").
thanks,
--lukas
Once they all end up under one repo, the
api and tcks will be released together. When you do a RC for API, you
will have a RC for TCK. I don't get why using the same release of TCK RC
is not acceptable.
Thanks
Emily
On Wed, Jan 26, 2022 at 1:42 AM Scott Stark <starksm64@xxxxxxxxx
<mailto:starksm64@xxxxxxxxx>> wrote:
The TCK cannot be an RC as it is part of the specification commit
project PR that is being balloted on for final ratification. At that
point there needs to be a staged final API artifact, specifications,
java doc, and TCK. The compatibility request is verified against the
final candidate TCK referenced in the PR. If the ratification ballot
passes, the staged TCK is promoted to the final TCK without
modification. All that process does is add the signing signatures of
the specification committee.
On Jan 25, 2022 at 4:54:41 PM, Emily Jiang via jakarta.ee-spec
<jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>>
wrote:
+1 on clarifying this.
For rectifying a spec, the viable solution is to use release
candidates for both APIs and TCKs to avoid chicken egg situations.
It has been a requirement that the TCK used for certification
was the proposed final TCK, but not the APIs.
Based on what I said above, TCKs used for ratifying a spec can be
a RC as well. This will certainly help with the specs that contain
both APIs and TCKs.
Thanks
Emily
On Tue, Jan 25, 2022 at 8:57 PM David Blevins
<dblevins@xxxxxxxxxxxxx <mailto:dblevins@xxxxxxxxxxxxx>> wrote:
Agree. If the signature tests pass, all is fine and the
vendor is allowed to use their own API jars. In some cases
those API jars are implementations: Faces, Activation, Mail,
etc. There are other situations like JACC where the API jar
can't really be considered an implementation, but there is
definitely significant code there.
We'd likely want to document those requirements in the JESP as
the EFSP is what currently holds the open source requirement.
We may need to add some clarification on the API jars produced
by specification projects as people are increasingly referring
to them as "the official" jars, implying 1) all other jars are
not official or lesser and 2) they must be used by the
compatible implementation used for ratification. Neither is
the case. We need some explicit text that says we have no
concept of "the official" jars and any jars that pass the TCK
and signature tests are equivalent.
For Jakarta EE 8 our compatible implementation was a
pre-Eclipse version of GlassFish that did not ship the jars
produced by the Specification Projects. We did do some work
to ensure the Specification Project-produced jars could pass a
TCK run. If we have thoughts that this should or does not
need to happen again if a compatible implementation does not
use the Specification Project-produced jars, we should write
that down too.
--
David Blevins
http://twitter.com/dblevins
<https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4I6KlrjN4$>
http://www.tomitribe.com
<https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4IdNRUiaY$>
> On Jan 25, 2022, at 9:28 AM, Scott Stark
<starksm64@xxxxxxxxx <mailto:starksm64@xxxxxxxxx>> wrote:
>
> An issue that came up during the platform call was what are
the requirements for the compatible implementation that is
used to ratify a specification. A specification team had
decided that they could not produce an RC that could be used
for such a ratification based on their interpretation of the
following two document statements:
>
> • According to
https://www.eclipse.org/projects/handbook/#specifications-implementations
<https://urldefense.com/v3/__https://www.eclipse.org/projects/handbook/*specifications-implementations__;Iw!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4Ihhw5S4M$>
“Compatible Implementations may only claim compatibility with
a final specification. ... No claims regarding compatibility
may be made for an implementation milestone build or
unratified specification version."
> •
https://github.com/jakartaee/specifications/blob/master/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md
<https://urldefense.com/v3/__https://github.com/jakartaee/specifications/blob/master/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4Im9ZJ3aM$>,
which states, "For a Release Review, a summary that a
Compatible Implementation is complete, passes the TCK, and
that the TCK includes sufficient coverage of the specification."
>
> If I look really pedantically at these two statements, maybe
I could read that only final APIs can be used by a compatible
implementation, but this is also ignoring other discussions we
have had about the special nature of the compatible
implementation used to ratify a specification.
>
> We need to make a clear statement about the requirements for
the initial compatible implement(s) used to ratify a
specification as well as any additional constraints on post
ratification compatible implementation claims.
>
> It has been common practice in EE and MP to use ratifying
compatible implementations that do depend on release candidate
APIs. It has been a requirement that the TCK used for
certification was the proposed final TCK, but not the APIs. By
virtue of passing the TCK signature tests, whatever API
versions the compatible implementation used, they have been
validated as compatible as determined by the final TCK. This
should be a sufficient validation of the compatible
implementation.
>
> Let's discuss tomorrow.
>
> _______________________________________________
> jakarta.ee-spec mailing list
> jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4ILEinWMQ$>
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4ILEinWMQ$>
--
Thanks
Emily
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4ILEinWMQ$>
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!cbgMFyFZwbH4kxld-okeMCnqzEtP7QLPfPa_KrmkR7aBbEbbJwAZqor65C4IayV5OYs$
