[RESTEASY-3030] Rename additional references to JAX-RS and Java EE.

https://issues.redhat.com/browse/RESTEASY-3030
Signed-off-by: James R. Perkins <jperkins@redhat.com>

docbook/reference/en/en-US/master.xml

@@ -59,7 +59,7 @@
                 <!ENTITY Validation SYSTEM "modules/Validation.xml">
                 <!ENTITY CORS SYSTEM "modules/cors.xml">
                 <!ENTITY I18N SYSTEM "modules/I18N.xml">
-                <!ENTITY JAX-RS_2.1_additions SYSTEM "modules/JAX-RS_2.1_additions.xml">
+                <!ENTITY Jakarta_REST_2.1_additions SYSTEM "modules/Jakarta_REST_2.1_additions.xml">
                 <!ENTITY REST-API "Jakarta RESTful Web Services">
                 ]>
 
@@ -127,7 +127,7 @@ This one is short
     &Json;
     &Json-p;
     &Multipart;
-   &JAX-RS_2.1_additions;
+   &Jakarta_REST_2.1_additions;
    &StringConverter;
    &Responses_using_javax.ws.rs.core.Response;
    &ExceptionMappers;

docbook/reference/en/en-US/modules/Asynchronous_HTTP.xml

@@ -16,7 +16,7 @@
    <sect1>
       <title>Using the <code>@Suspended</code> annotation</title>
       <para>
-         The JAX-RS 2.0 specification has added asynchronous HTTP support via two classes.  The <code>@Suspended</code> annotation,
+         The &REST-API; specification includes asynchronous HTTP support via two classes. The <code>@Suspended</code> annotation,
          and AsyncResponse interface.
       </para>
       <para>
@@ -76,7 +76,7 @@ public class SimpleResource
    <sect1>
       <title>Using Reactive return types</title>
       <para id="CompletionStage">
-          The JAX-RS 2.1 specification adds support for declaring asynchronous resource methods by
+          The &REST-API; 2.1 specification adds support for declaring asynchronous resource methods by
           returning a <code>CompletionStage</code> instead of using the <code>@Suspended</code>
           annotation.
       </para>

docbook/reference/en/en-US/modules/Configuring_Individual_Jakarta_REST_Resource_Beans.xml

@@ -7,7 +7,7 @@
 </para>
 <para>
 
-If you are scanning your path for &REST-API; annotated resource beans, your beans will be registered in per-request mode.  This means an instance will be created per HTTP request served.  Generally, you will need information from your environment.  If you are running within a servlet container using the WAR-file distribution, in 1.0.0.Beta-2 and lower, you can only use the JNDI lookups to obtain references to Java EE resources and configuration information.  In this case, define your EE configuration (i.e. ejb-ref, env-entry, persistence-context-ref, etc...) within web.xml of the resteasy WAR file.  Then within your code do jndi lookups in the java:comp namespace.  For example:
+If you are scanning your path for &REST-API; annotated resource beans, your beans will be registered in per-request mode.  This means an instance will be created per HTTP request served.  Generally, you will need information from your environment.  If you are running within a servlet container using the WAR-file distribution, in 1.0.0.Beta-2 and lower, you can only use the JNDI lookups to obtain references to Jakarta EE resources and configuration information.  In this case, define your EE configuration (i.e. ejb-ref, env-entry, persistence-context-ref, etc...) within web.xml of the resteasy WAR file.  Then within your code do jndi lookups in the java:comp namespace.  For example:
 </para>
 <para>
 

docbook/reference/en/en-US/modules/Installation_Configuration.xml

@@ -120,14 +120,24 @@
                 </row>
                 <row>
                     <entry>
-                        org.jboss.resteasy.resteasy-jaxrs
+                        org.jboss.resteasy.resteasy-core
                     </entry>
                     <entry>
                         yes
                     </entry>
                     <entry>
-                        Core RESTEasy libraries for server and client.  You will need to include this in your deployment
-                        if you are only using &REST-API; client.
+                        Core RESTEasy libraries for server.
+                    </entry>
+                </row>
+                <row>
+                    <entry>
+                        org.jboss.resteasy.resteasy-client
+                    </entry>
+                    <entry>
+                        yes
+                    </entry>
+                    <entry>
+                        Core RESTEasy libraries for client.
                     </entry>
                 </row>
                 <row>
@@ -355,7 +365,7 @@ public class MyApplication extends Application
         <para>
             If you are using RESTEasy outside of WildFly, in a standalone servlet container like Tomcat or Jetty, for example,
             you will need to include the appropriate RESTEasy jars in your WAR file.  You will need the core classes
-            in the resteasy-jaxrs module, and you may need additional facilities like the resteasy-jaxb-provider module.
+            in the resteasy-core and resteasy-client modules, and you may need additional facilities like the resteasy-jaxb-provider module.
             We strongly suggest that you use Maven to build your WAR files as RESTEasy is split into
             a bunch of different modules:
         </para>
@@ -365,6 +375,11 @@ public class MyApplication extends Application
     <artifactId>resteasy-core</artifactId>
     <version>5.0.0-SNAPSHOT</version>
 </dependency>
+<dependency>
+    <groupId>org.jboss.resteasy</groupId>
+    <artifactId>resteasy-client</artifactId>
+    <version>5.0.0-SNAPSHOT</version>
+</dependency>
 <dependency>
     <groupId>org.jboss.resteasy</groupId>
     <artifactId>resteasy-jaxb-provider</artifactId>
@@ -943,7 +958,7 @@ String value = ConfigProvider.getConfig().getOptionalValue("prop_name", String.c
                                 Replaces the need for an Accept header by mapping file name extensions (like .xml or
                                 .txt) to a media type. Used when the client
                                 is unable to use an Accept header to choose a representation (i.e. a browser). See
-                                <xref linkend="JAX-RS_Content_Negotiation"/> for more details.
+                                <xref linkend="Jakarta_REST_Content_Negotiation"/> for more details.
                             </entry>
                         </row>
                         <row>
@@ -1387,7 +1402,7 @@ public abstract class Application
     <title>Client side</title>
 
     <para>
-        JAX-RS 2.0 conforming implementations such as RESTEasy support a client side framework which simplifies
+        &REST-API; conforming implementations, such as RESTEasy, support a client side framework which simplifies
         communicating with restful applications. In RESTEasy, the minimal set of modules needed for the client framework
         consists of resteasy-core and resteasy-client. You can access them by way of maven:
     </para>

docbook/reference/en/en-US/modules/Interceptors.xml

@@ -1,6 +1,6 @@
 <chapter id="Interceptors">
     <title>Filters and Interceptors</title>
-    <para>JAX-RS 2.0 has two different concepts for interceptions: Filters and Interceptors.  Filters are mainly used to
+    <para>&REST-API; has two different concepts for interceptions: Filters and Interceptors.  Filters are mainly used to
     modify or process incoming and outgoing request headers or response headers.  They execute before and after
     request and response processing.</para>
     <sect1>

docbook/reference/en/en-US/modules/JAX-RS_2.1_additions.xml → docbook/reference/en/en-US/modules/Jakarta_REST_2.1_additions.xml

@@ -1,6 +1,6 @@
-<chapter id="JAX-RS_2.1_additions">
-    <title>JAX-RS 2.1 Additions</title>
-    <para>JAX-RS 2.1 adds more asynchronous processing support in both the
+<chapter id="Jakarta_REST_2.1_additions">
+    <title>&REST-API; 2.1 Additions</title>
+    <para>&REST-API; 2.1 adds more asynchronous processing support in both the
         Client and the Server API.  The specification adds a Reactive programming
         style to the Client side and Server-Sent Events (SSE) protocol support to
         both client and server.
@@ -48,7 +48,7 @@
              The field can be event, data, id, retry and other kinds of field will be ignored.
         </para>
         <para>
-             From JAX-RS 2.1, Server-sent Events APIs are introduced to support sending, receiving and broadcasting SSE events.
+             From &REST-API; 2.1, Server-sent Events APIs are introduced to support sending, receiving and broadcasting SSE events.
         </para>
         <sect2>
             <title>SSE Server</title>
@@ -200,7 +200,7 @@
         </para>
         <para>
             The support for JSON-B is provided by the <code>JsonBindingProvider</code> from <code>resteasy-json-binding-provider</code> module.
-            To satisfy JAX-RS 2.1 requirements, JsonBindingProvider takes precedence over the other providers for dealing with JSON payloads,
+            To satisfy &REST-API; 2.1 requirements, JsonBindingProvider takes precedence over the other providers for dealing with JSON payloads,
             in particular the Jackson one. The JSON outputs (for the same input) from Jackson and JSON-B reference implementation can be slightly
             different.  As a consequence, in order to allow retaining backward compatibility, RESTEasy offers a
             <code>resteasy.preferJacksonOverJsonB</code> context property that can be set to <code>true</code> to disable JsonBindingProvider

docbook/reference/en/en-US/modules/Jaxb.xml

@@ -2,7 +2,7 @@
    <title>JAXB providers</title>
 
    <para>
-      As required by the specification, RESTEasy &REST-API; includes support for (un)marshalling JAXB annotated classes.
+      As required by the specification, RESTEasy includes support for (un)marshalling JAXB annotated classes.
       RESTEasy provides multiple JAXB Providers to address some subtle differences between classes generated by XJC
       and classes which are simply annotated with @XmlRootElement, or working with JAXBElement classes directly.
    </para>

docbook/reference/en/en-US/modules/Json-p.xml

@@ -1,6 +1,6 @@
 <chapter id="json-p">
     <title>JSON Support via Jakarta EE JSON-P API</title>
-    <para>No, this is not the JSONP you are thinking of!  JSON-P is a Jakarta EE parsing API introduced in Java EE 7.
+    <para>No, this is not the JSONP you are thinking of! JSON-P is a Jakarta EE parsing API.
         Horrible name for
         a new JSON parsing API!  What were they thinking?  Anyways, RESTEasy has
         a provider for it.  If you are using WildFly, it is required by Jakarta EE so you will have it automatically bundled.

docbook/reference/en/en-US/modules/Migration_from_older_versions.xml

@@ -40,12 +40,12 @@
 
     <orderedlist>
       <listitem>
-      <para><emphasis role="bold">RESTEasy 2</emphasis>: RESTEasy 2 conforms to the JAX-RS 1 specification, and adds a
+      <para><emphasis role="bold">RESTEasy 2</emphasis>: RESTEasy 2 implements the JAX-RS 1 specification, and adds a
       variety of additional facilities, such as a client API, a caching system, an interceptor framework, etc. 
       All of these user facing classes and interfaces comprise the RESTEasy 2 API.</para>
       </listitem>
       <listitem>
-      <para><emphasis role="bold">RESTEasy 3</emphasis>: RESTEasy 3 conforms to the JAX-RS 2 specification, and adds some additional
+      <para><emphasis role="bold">RESTEasy 3</emphasis>: RESTEasy 3 implements the JAX-RS 2 specification, and adds some additional
       facilities. Many of the non-spec facilities from the RESTEasy 2 API are formalized, in altered form,
       in JAX-RS 2, in which case the older facilites are deprecated. The non-deprecated user facing classes and interfaces in
       RESTEasy 3 comprise the RESTEasy 3 API.</para>
@@ -145,7 +145,7 @@ URI uri = uriInfo.getBaseUriBuilder().path("test").build();
       <para>
       This issue is related to refactoring deprecated elements of the RESTEasy 2 API into a separate module, and, ideally,
       would have no bearing at all on RESTEasy 3. However, a reorganization of packages has led to moving some
-      non-deprecated API elements in the resteasy-jaxrs module:
+      non-deprecated API elements in the resteasy-core module:
       </para>
 
       <itemizedlist>
@@ -217,12 +217,12 @@ URI uri = uriInfo.getBaseUriBuilder().path("test").build();
 <sect1>
     <title>Migration to RESTEasy 3.5+ series</title>
     <para>
-      RESTEasy 3.5 series is a spin-off of the old RESTEasy 3.0 series, featuring JAX-RS 2.1 implementation.
+      RESTEasy 3.5 series is a spin-off of the old RESTEasy 3.0 series, featuring &REST-API; implementation.
     </para>
     <para>
       The reason why 3.5 comes from 3.0 instead of the 3.1 / 4.0 development streams is basically providing
       users with a selection of RESTEasy 4 critical / strategic new features, while ensuring full backward
-      compatiblity. As a consequence, no major issues are expected when upgrading RESTEasy from 3.0.x to 3.5.x.
+      compatibility. As a consequence, no major issues are expected when upgrading RESTEasy from 3.0.x to 3.5.x.
       The 3.6 and all other 3.x minors after that are backward compatible evolutions of 3.5 series.
     </para>
     <para>

docbook/reference/en/en-US/modules/Overview.xml

@@ -23,19 +23,7 @@ that provide a Java API for RESTful Web Services over the HTTP protocol:
     <entry><ulink url="https://jcp.org/en/jsr/detail?id=339">JAX-RS 2.0</ulink></entry>
   </row>
   <row>
-    <entry>3.5-3.15.2</entry>
-    <entry><ulink url="https://jcp.org/en/jsr/detail?id=370">JAX-RS 2.1</ulink></entry>
-  </row>
-  <row>
-    <entry>3.9+</entry>
-    <entry><ulink url="https://jakarta.ee/specifications/restful-ws/2.1/restful-ws-spec-2.1.html">Jakarta RESTful Web Services 2.1</ulink></entry>
-  </row>
-  <row>
-    <entry>4.0-4.7.2</entry>
-    <entry><ulink url="https://jcp.org/en/jsr/detail?id=370">JAX-RS 2.1</ulink></entry>
-  </row>
-  <row>
-    <entry>4.3+</entry>
+    <entry>3.5+</entry>
     <entry><ulink url="https://jakarta.ee/specifications/restful-ws/2.1/restful-ws-spec-2.1.html">Jakarta RESTful Web Services 2.1</ulink></entry>
   </row>
 </tbody>

docbook/reference/en/en-US/modules/RESTEasy_Client_Framework.xml

@@ -2,8 +2,8 @@
     <title>RESTEasy Client API</title>
 
     <section>
-        <title>JAX-RS 2.0 Client API</title>
-        <para>JAX-RS 2.0 introduces a new client API so that you can make http requests to your remote RESTful web services.
+        <title>&REST-API; Client API</title>
+        <para>The &REST-API; includes a client API so that you can make http requests to your remote RESTful web services.
         It is a 'fluent' request building API with really 3 main classes:  Client, WebTarget, and Response.  The Client
         interface is a builder of WebTarget instances.  WebTarget represents a distinct URL or URL template from which
         you can build more sub-resource WebTargets or invoke requests on.</para>

docbook/reference/en/en-US/modules/Reactive.xml

@@ -2,7 +2,7 @@
 <title>Reactive programming support</title>
 
     <para>
-       With version 2.1, the JAX-RS specification 
+       With version 2.1, the &REST-API; specification
        (<ulink url="https://jcp.org/en/jsr/detail?id=370">https://jcp.org/en/jsr/detail?id=370</ulink>)
        takes its first steps into the world of <emphasis role="bold">Reactive Programming</emphasis>. There are many discussions
        of reactive programming on the internet, and a general introduction is beyond the scope of this document,
@@ -25,8 +25,8 @@
 <sect1>
 <title>CompletionStage</title>
     <para>
-       In java 1.8 and JAX-RS 2.1, the support for reactive programming is fairly limited. Java 1.8 introduces the interface
-       <classname>java.util.concurrent.CompletionStage</classname>, and JAX-RS 2.1 mandates support for the
+       In Java 1.8 and &REST-API;, the support for reactive programming is fairly limited. Java 1.8 introduces the interface
+       <classname>java.util.concurrent.CompletionStage</classname>, and &REST-API; mandates support for the
        <classname>javax.ws.rs.client.CompletionStageRxInvoker</classname>, which allows a client to obtain a 
        response in the form of a <classname>CompletionStage</classname>. 
     </para>
@@ -175,7 +175,7 @@ private CompletionStage&lt;String&gt; getCompletionStageSupplyAsync1(String s, E
 <title>CompletionStage in &REST-API;</title>
 
     <para>
-       On the client side, the JAX-RS 2.1 specification mandates an implementation of the interface
+       On the client side, the &REST-API; specification mandates an implementation of the interface
        <classname>javax.ws.rs.client.CompletionStageRxInvoker</classname>:
     </para>
 
@@ -221,7 +221,7 @@ log.info("result: " + s);
 </programlisting>
 
     <para>
-       On the server side, the JAX-RS 2.1 specification requires support for resource methods with return type
+       On the server side, the &REST-API; specification requires support for resource methods with return type
        <classname>CompletionStage&lt;T&gt;</classname>. For example,
     </para>
 
@@ -673,7 +673,7 @@ public interface FlowableOnSubscribe&lt;T&gt; {
 <title>Client side</title>
 
     <para>
-       On the client side, JAX-RS 2.1 supports extensions for reactive classes by adding the method
+       On the client side, &REST-API; supports extensions for reactive classes by adding the method
     </para>
 
 <programlisting>
@@ -1359,7 +1359,7 @@ public interface AsyncStreamProvider&lt;T&gt; {
     </para>
 
     <para>
-       <emphasis role="bold">Client side.</emphasis> The JAX-RS specification version 2.1 imposes two
+       <emphasis role="bold">Client side.</emphasis> The &REST-API; specification imposes two
        requirements for support of reactive classes on the client side:   
     </para> 
 

docbook/reference/en/en-US/modules/StringConverter.xml

@@ -53,7 +53,7 @@ public void testQuery() throws Exception {
 
    <para>
    What if you have a class where <methodname>valueOf()</methodname>or this string constructor don't exist or are inappropriate
-   for an HTTP request? JAX-RS 2.0 has the <classname>javax.ws.rs.ext.ParamConverterProvider</classname> to help
+   for an HTTP request? &REST-API; has the <classname>javax.ws.rs.ext.ParamConverterProvider</classname> to help
    in this situation.
    </para>
 
@@ -670,7 +670,7 @@ public static class TestResource {
    <title>Default multiple valued <classname>ParamConverter</classname></title>
 
    <para>
-   RESTEasy includes two built-in <classname>ParamConverter</classname>s in the resteasy-jaxrs module,
+   RESTEasy includes two built-in <classname>ParamConverter</classname>s in the resteasy-core module,
    one for <classname>Collection</classname>s:
    </para>
 

docbook/reference/en/en-US/modules/Validation.xml

@@ -3,7 +3,7 @@
 
    <para>
    RESTEasy provides the support for validation mandated by the
-   <ulink url="http://www.jcp.org/en/jsr/detail?id=339">JAX-RS: Java API for RESTful Web Services 2.1 </ulink>,
+   <ulink url="https://jakarta.ee/specifications/restful-ws/">&REST-API;</ulink>,
    given the presence of an implementation of the
    <ulink url="https://beanvalidation.org/2.0/spec/">Bean Validation specification</ulink>
    such as <ulink url="http://hibernate.org/validator/">Hibernate Validator</ulink>. 
@@ -316,7 +316,7 @@ path fields. [See <xref linkend="microprofile_config"/> for more information abo
          <title>Validation Service Providers</title>
 
             <para>
-   The form of validation mandated by the JAX-RS 2.1 specification, based on Bean Validation 1.1 or greater,
+   The form of validation mandated by the &REST-API; specification, based on Bean Validation 1.1 or greater,
    is supported by the RESTEasy module resteasy-validator-provider, which produces the artifact
    resteasy-validator-provider-&lt;version&gt;.jar.  Validation is turned on by default (assuming
    resteasy-validator-provider-&lt;version&gt;.jar is available), though