One thing I would like to exclude is any requirement that a compatible
implementation, used for release ballot, must be exactly build-able at
any time in the future.
The compatible implementation used for release ballot must be
open-source. We can require that the source be preserved (we kind of
imply that the candidate be "released" in some manner but I don't
believe we are detailed in that requirement and I don't think we need to
be). In my opinion, it should not be an obligation of a prospective
ballot CI to provide, nor support building of that release at any time
in the future. (If a prospective ballot CI wants to offer this -- great
-- it simply is not an obligation.)
One issue that frequently comes up in the product release end-game is
the need to update pom file GAVs from <package>.bxx.yy (bxx or rcx or
whatever) to <package>.yy. Most commonly this is done when all the
various components have finalized their releases and the project team
does a sweep that moves all the prospective-final GAVs to their
final-final GAVs. In our current release methodology, an early ballot CI
may need to wait for quite some time before all the dependencies which
were used to build and validate /that/ implementation become final in
themselves.
If we require source preservation or tagging or whatever -- I would
propose "for reference only" be the totality of what is required. Pom
file changes (like I've described above) should not invalidate the
prospective CI. Nor, would I say that inclusion of components that are,
themselves still evolving, be disallowed.
The CI must pass the TCK. The TCK includes tests and instructions. The
Specification Team and the CI implementer assert that all the tests
cover what they should cover (behavior and signatures). That's all there is.
Even if we wind up not agreeing to this point, we should clarify this
(whatever the prospective CI requirements are) so it's clear to our
community.
-- Ed
On 1/25/2022 12:56 PM, David Blevins 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.
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
