Where we already have separate projects
            for the specifications (APIs) and the implementation,
            they'll remain separate at the Eclipse Foundation.  For
            example, "Eclipse WebSocket API for Java" is the API
            specification project and "Eclipse Tyrus" is the
            implementation project.
            
            In some cases, such as Eclipse JSON Processing, the existing
            project contains both the API classes and the implementation
            classes.  After the initial project is established at
            Eclipse, the EE4J community can choose to do the work to
            split that project into two projects if desired.
            
            We've decided to rename the specification projects from
            (e.g.) "Eclipse RESTful Web Services API for Java" to
            "Eclipse Project for JAX-RS".  That should make it clear
            what the intent of the project is, while conforming to
            Oracle trademark guidelines.
            
            Yes, the JAX-RS JSR reference is wrong; we'll fix that.
            
            Sebastian Daschner wrote on 11/21/17 10:51 AM:
         
        
          Hi there,
            
            It's great to see some progress. However, there are a few
            things in that announcement that puzzle me. Apologies
            upfront for any stupid questions, I'm just trying to make
            sense out of it.
            
            First of all, these project proposals seem to throw both
            specifications and RIs into one pot. I guess it makes sense
            to create Eclipse projects for implementations such as Tyrus
            or Jersey. Are the specifications also planned to be
            incorporated as Eclipse projects? Or will there be
            standardization processes, what the JSRs with EGs are today?
            Especially in regard to the overall platform, which JSR 366
            is today. I'm not familiar with what is planned to be the
            substitute for JSRs & EGs, but maybe it makes sense for
            the Java EE community to see some suggestion there first.
            
            Do the specifications need to adopt the name Eclipse? In the
            EE4J FAQ #7 it says that the intention is to continue to use
            the former JCP specification names, such as 'Java API for
            RESTful Web Services'. I know that names are what people get
            religious about, but still I believe that we should not
            choose some names for specifications before the name for
            what will succeed Java EE (e.g. Open EE) is carved into
            stone. IMO 'Eclipse RESTful Web Services API for Java' is a
            bad substitute for JAX-RS.
            
            I only checked the Eclipse analog for the JAX-RS so far, but
            that refers to JSR 339, which is JAX-RS 2.0, not JSR 370.
            Since EE4J should be aligned with EE 8, shouldn't that refer
            to the current specification?
            
            Cheers,
            Sebastian
            (JSR 370, 374, 382)
           
          
            On 11/21/2017 05:33 PM, Mike
              Milinkovich wrote:
           
          
            All,
            I would like to draw your attention to fact that nine new
              EE4J project proposals were recently posted on the Eclipse
              Foundation's proposal page. This is the
              first step to making the migration of Java EE to the
              Eclipse Foundation a reality.
            The list of proposals is below. There are more details on
              the proposal page, or on my blog post. 
            Thanks!
            
              Eclipse Tyrus
                Eclipse OpenMQ
                Eclipse Grizzly
                Eclipse Jersey
                Eclipse RESTful Web Services API for Java
                Eclipse Message Service API for Java
                Eclipse WebSocket API for Java
                Eclipse Mojarra
                Eclipse JSON Processing
            
            
            
              
              
              
            _______________________________________________
            ee4j-community mailing list
            ee4j-community@xxxxxxxxxxx
            To change your delivery options, retrieve your password, or unsubscribe from this list, visit
            https://dev.eclipse.org/mailman/listinfo/ee4j-community
          
          
            
            
            
            
          _______________________________________________
          ee4j-community mailing list
          ee4j-community@xxxxxxxxxxx
          To change your delivery options, retrieve your password, or unsubscribe from this list, visit
          https://dev.eclipse.org/mailman/listinfo/ee4j-community