[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance tests | 
  
  
    I don't know where to jump in on this thread.
    Nothing in the rules says one single product must implement all
      optional features. I'd like to make two points:
    
    First, what I think the rules and specifications say:
    
    1. If a feature is included in Jakarta EE, it must have a TCK.
    2. If a feature in the platform is specified as Optional, the
      platform that certifies compatibility of that feature must include
      all other Required features. (This is also true for component
      specifications, just replace component-name for platform.)
    
    3. If there are multiple independent optional features, nothing
      says one single implementation must deliver all the separate
      optional features. There must be one of each, but I believe they
      can be separate compatible implementations.
    Second, the hard dependency Jakarta EE has on Eclipse GlassFish:
    Eclipse GlassFish is required today because that's how we build
      TCKs for 25 for Specs that come from this project. Once the
      working group and/or API project teams refactor how these TCKs are
      built and remove the dependency on Eclipse GlassFish, that
      requirement goes away. This is not a requirement of our rules or
      specification. It's just a consequence of how the Jakarta EE TCK
      project implements what it does.
    Currently Jakarta EE benefits from Eclipse GlassFish because it
      implements all features, required or optional. This was a
      consequence of the previous Reference Implementation concept.
      Nothing in the Jakarta EE rules forces Eclipse GlassFish to be
      used this way. On the other hand, Jakarta EE is able to provide
      degrees of freedom to implementers because Eclipse GlassFish
      conveniently has those features. This is not a requirement of our
      rules or specifications. Eclipse GlassFish could be replaced if
      there were another suitable implementation that fills its place.
    
    -- Ed
    
    
    
    On 7/2/2020 8:08 AM, Kevin Sutter
      wrote:
    
    
      
      Scott,
      Even if it
        doesn't
        make sense, I think those are the rules...  At least for these
        initial
        removed features.  For example, let's pretend the Open Liberty
        wanted
        to continue to support J2EE Management after it was removed from
        Jakarta
        EE 9.  J2EE Management was originally part of Java EE and under
        the
        javax namespace.  Thus, falling under the old rules put in place
        by
        the JCP.  If an app server ships the J2EE Management API, then a
        corresponding
        implementation which passes the TCK is required.
      
      That's the
        way
        that I have always understood the rules concerning Java EE.
         Now,
        if someone can cite an alternate understanding, then I'm happy
        to be corrected.
         Or, maybe something changed since we shipped J2EE Management
        with
        Jakarta EE 8?  I didn't think so since it still uses the javax
        namespace.
         Maybe someone from Oracle needs to clarify the requirements?
      
      (BTW, this is
        another advantage of moving to the jakarta namespace.  We can
        define
        our own rules going forward for removed features post Jakarta EE
        9.)
      
        ---------------------------------------------------
        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:
               Scott
        Stark <starksm64@xxxxxxxxx>
      To:
               jakartaee-platform
        developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
      Date:
               07/02/2020
        09:35
      Subject:
               [EXTERNAL]
        Re: [jakartaee-platform-dev] Fair rules for "optional" TCK
        compliance
        tests (was: Inconsistency on the term "pruned")
      Sent
        by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx
      
      
      
      That does not make sense. Once
        removed
        from the platform, it is a vendor specific feature. It is up to
        them how
        they test that feature, and that can not be a requirement for
        certification.
      
      On Thu, Jul 2, 2020 at 9:00 AM Kevin
        Sutter <sutter@xxxxxxxxxx>
        wrote:
      Correct. 
        Removed features can continue to be shipped and packaged with a
        compliant
        app server.  The TCK from the past release would still need to
        be
        executed and passed for these removed features.
        
        
        ---------------------------------------------------
        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:        Gurkan
        Erdogdu <cgurkanerdogdu@xxxxxxxxx>
        To:        jakartaee-platform
        developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
        Date:        07/02/2020
        08:31
        Subject:        [EXTERNAL]
        Re: [jakartaee-platform-dev] Fair rules for "optional" TCK
        compliance
        tests (was: Inconsistency on the term "pruned")
        Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx
      
      
      
      I
          thought we did away with the restriction that removed features
          cannot be
          shipped
      
          IMHO, you can ship but when you ship, you need the pass the
          related TCK
          suite
        _______________________________________________
            jakartaee-platform-dev mailing list
            jakartaee-platform-dev@xxxxxxxxxxx
            To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
          
      
      
      
      _______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev