[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [jakarta.ee-community] [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan | 
  
  
    Hi Scott,
    If you take a look at the long-standing items in the Jakarta EE
      Ambassadors' Contributor Guide
(https://jakartaee-ambassadors.io/guide-to-contributing-to-jakarta-ee-11/),
      the following items are along these lines:
     * Modernizing the TCK to take advantage of Maven, JUnit,
      Arquillian, etc. It has long been well understood that not doing
      this work reduces the velocity of releases of the platform and
      older specifications. It also makes the TCK inaccessible to new
      contributors. My understanding from Ed is that this is well on the
      way to being resolved now. That's why I did not include it in the
      Jakarta EE 12 potential plan. Is that not the case? Also,
      unfortunately most users and customers would not really care about
      this, so it has to be balanced with more marketable changes.
    * Making specification TCKs standalone as much as possible and
      making more specifications usable on their own in plain Java SE,
      without a Jakarta EE runtime. This should include bootstrap APIs
      for things like Messaging and Servlet. Indeed this could include a
      Java SE bootstrap API for Jakarta EE itself. If there is appetite
      for it, consensus around it, and we take it seriously to get it
      really done, this could be a very nice marketable item for Jakarta
      EE 12. The reason I did not include it is because I assess this to
      be an even steeper effort as compared with what I already included
      that could make EE 12 get some real market attention.
    
    * Improving testing for Jakarta EE. This could take several
      forms. It could simply mean accepting that Arquillian is the
      de-facto answer and making sure it is as good as it can be (and I
      think currently it is not). It could be moving Arquillian to the
      Foundation and improving it there (would Red Hat be open to
      this?). It could mean basically standardizing the Arquillian API
      into Jakarta EE. It could also mean taking a fresh look at
      standardizing a testing API by looking at things like
      Testcontainers. Any of these could be pretty marketable for
      Jakarta EE 12. The reason I did not include it is that in my
      assessment this will take an even longer time to figure out than
      what I already listed.
    Is any/some of these things what you had in mind or are you
      thinking of something else we had not already identified for a
      while as a critical gap?
    
    Thanks,
    Reza
    
    On 10/27/2024 4:19 AM, Scott Marlow
      wrote:
    
    
      
      
        
          
          
            
            
              
                
                   
                  
                    BTW I want to see how far I can push
                      this forward by October 31, roughly when the
                      Steering Committee Program Plan needs to be
                      finalized. If you can at least post something on
                      those mailing lists by then, I believe it will
                      make some difference.
                   
                 
               
            
           
         
        
        
        Please also consider steps to bring more quality
          into our existing releases to help EE applications to get more
          out of their code base including making changes in their
          applications.  Any thoughts on how we could figure out what
          that could look like?