Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [ejb-dev] [External] : Please give your estimate of when you will complete your tasks for Jakarta EE 9.1 TCKs ...

On 3/19/21, 5:21 PM, "David Blevins" <dblevins@xxxxxxxxxxxxx> wrote:

    > On Mar 19, 2021, at 9:03 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
    > 
    > On 3/19/21, 4:43 PM, "David Blevins" <dblevins@xxxxxxxxxxxxx> wrote:
    > 
    >> On Mar 19, 2021, at 8:39 AM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
    >> 
    >> If we're releasing a new spec, we should release a new TCK so the versions match.
    > 
    > We are releasing a new _Platform_  spec, not new Activation, Mail, etc... specs, JAF and Mail service releases were able to pass existing 9.0 standalone TCKs on both - JDK 8 as well as JDK 11.
    > Given that NO API changes were allowed in included specs, I'd expect that the new 9.1 platform release implementation should pass even the 9.0 platform TCK release `as is` at least on JDK 8 (I don't recall if JDK 8 is a "must" right now but I think you get the point). Don't take me wrong, I understand the need for the new Platform TCK release. It's just about that the Platform itself advertised that nothing should be changed at the components/included specs level.

    I'm a little confused.  There will be new tests and other changes for the 9.1 TCK, so the TCKs won't be the same and someone would not be able to use the 9.0 TCK to claim compatibility with 9.1.

let me try it from the different end.. Activation TCK 9.0.0 release was/is able to verify compliance with the Activation 2.0 spec on both - Java 8 as well as Java 11, including verifying signatures. Platform 9.1 defines that it includes Activation spec v. 2.0. Platform does not care about particular service release of the activation spec implementation as long as it complies with the 2.0 spec version, so it should not matter whether there is activation spec implementation 2.0.0, 2.0.1 or 2.0.436 in the platform implementation as long as it passes Activation TCK 9.0.0. This should be reflected at the platform-level TCK in the same manner - Platform 9.1 TCK release should just include/reuse existing Activation TCK 9.0.0 release unless there is some blocker for running 9.0.0 version of the Activation TCK on Java 11 (like ie missing signature files) or some change in Activation TCK needed by the Platform TCK - so far I'm not aware of any request for such change and if there is, then it is not in the jaf-tck issue tracker.

If we want to get to the point where we want to be able to say that Platform 9.1 and Platform TCK 9.1 are fully built by, on and for Java 11, then yes, even these standalone TCKs require an update as those 9.0.0 releases were mostly built by Java 8.
We also may want to somehow align platform and standalone TCK version numbers but that is something one would need to know about and also something what should be put into a different thread as Scott has suggested already.

thanks,
--lukas


    We do need to prove that the 9.1 TCK can be passed on JDK 8 and there's no way to cut that corner.  That said, we still probably can use GlassFish 6 to pass the 9.1 TCK on JDK 8 so there shouldn't be extra work.


    Scott Marlow, are we running the 9.1 TCK on JDK 8 in addition to 11 and are we factoring passing both into our timelines?

    >    That said, the signature files will likely have changed because we added signature test files for each API on Java 11.
    > 
    > Some standalone TCKs already included signature tests for Java 11 in 9.0 release.

    For any standalone TCKs that have new signature files, we'd at least need a service release of each.

this is clear, no problem with that.


    -David



Back to the top