Vote succeeded, create the 5.1 tag

git-svn-id: https://svn.apache.org/repos/asf/jmeter/tags/v5_1@1853819 13f79535-47bb-0310-9956-ffa450edef68

Former-commit-id: 14c749202ec6fac7aad854410d782b47b34de9c3
diff --git a/build.xml b/build.xml
index 42251b6..512f876 100644
--- a/build.xml
+++ b/build.xml
@@ -592,7 +592,7 @@
       JMeter version
       This is overridden for formal releases.
     -->
-    <property name="jmeter.version" value="5.1-SNAPSHOT"/>
+    <property name="jmeter.version" value="5.1"/>
     <!-- Remember to change "docversion" below if necessary -->
     <condition property="implementation.version"
           value="${jmeter.version} r${svn.revision}" else="${jmeter.version}.${DSTAMP}">
diff --git a/src/core/org/apache/jmeter/JMeter.java b/src/core/org/apache/jmeter/JMeter.java
index 0a7c01a..ea86e6e 100644
--- a/src/core/org/apache/jmeter/JMeter.java
+++ b/src/core/org/apache/jmeter/JMeter.java
@@ -365,7 +365,7 @@
     private void startGui(String testFile) {
         System.out.println("================================================================================");//NOSONAR
         System.out.println("Don't use GUI mode for load testing !, only for Test creation and Test debugging.");//NOSONAR
-        System.out.println("For load testing, use NON GUI Mode:");//NOSONAR
+        System.out.println("For load testing, use CLI Mode (was NON GUI):");//NOSONAR
         System.out.println("   jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]");//NOSONAR
         System.out.println("& increase Java Heap to meet your test requirements:");//NOSONAR
         System.out.println("   Modify current env variable HEAP=\"-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m\" in the jmeter batch file");//NOSONAR
diff --git a/src/core/org/apache/jmeter/gui/action/ApplyNamingConvention.java b/src/core/org/apache/jmeter/gui/action/ApplyNamingConvention.java
index 23b813f..e607a4e 100644
--- a/src/core/org/apache/jmeter/gui/action/ApplyNamingConvention.java
+++ b/src/core/org/apache/jmeter/gui/action/ApplyNamingConvention.java
@@ -20,8 +20,10 @@
 
 import java.awt.Toolkit;
 import java.awt.event.ActionEvent;
+import java.util.ArrayList;
 import java.util.Enumeration;
 import java.util.HashSet;
+import java.util.List;
 import java.util.Set;
 
 import org.apache.jmeter.control.Controller;
@@ -52,20 +54,25 @@
     @Override
     public void doAction(ActionEvent e) {
         GuiPackage guiPackage = GuiPackage.getInstance();
-        JMeterTreeNode currentNode = guiPackage.getTreeListener().getCurrentNode();
-        if (!(currentNode.getUserObject() instanceof Controller)) {
-            Toolkit.getDefaultToolkit().beep();
-            return;
+        JMeterTreeNode[] currentNodes = guiPackage.getTreeListener().getSelectedNodes();
+        List<JMeterTreeNode> filteredNodes = new ArrayList<>();
+        for (JMeterTreeNode jMeterTreeNode : currentNodes) {
+            if (jMeterTreeNode.getUserObject() instanceof Controller) {
+                filteredNodes.add(jMeterTreeNode);
+            } else {
+                log.warn("Applying naming policy, selected node {} is not a Controller, will ignore it", jMeterTreeNode.getName());
+            }
         }
         try {
-            applyNamingPolicyToCurrentNode(guiPackage, currentNode);
+            for (JMeterTreeNode currentNode : filteredNodes) {
+                applyNamingPolicyToCurrentNode(guiPackage, currentNode);
+            }
             GuiPackage.getInstance().getMainFrame().repaint();
         } catch (Exception err) {
             Toolkit.getDefaultToolkit().beep();
             log.error("Failed to apply naming policy", err);
             JMeterUtils.reportErrorToUser("Failed to apply naming policy", err);
         }
-
     }
 
     /**
diff --git a/src/core/org/apache/jmeter/gui/action/SelectTemplatesDialog.java b/src/core/org/apache/jmeter/gui/action/SelectTemplatesDialog.java
index 23a3458..63d1fb7 100644
--- a/src/core/org/apache/jmeter/gui/action/SelectTemplatesDialog.java
+++ b/src/core/org/apache/jmeter/gui/action/SelectTemplatesDialog.java
@@ -101,7 +101,7 @@
     
     private final JButton previous = new JButton(JMeterUtils.getResString("previous")); //$NON-NLS-1$
     
-    private final JButton validateButton = new JButton(JMeterUtils.getResString("validate_threadgroup")); //$NON-NLS-1$
+    private final JButton validateButton = new JButton();
     
     private Map<String, JLabeledTextField> parametersTextFields = new LinkedHashMap<>();
     
@@ -352,6 +352,9 @@
         applyTemplateButton.setText(template.isTestPlan() 
                 ? JMeterUtils.getResString("template_create_from")
                 : JMeterUtils.getResString("template_merge_from") );
+        validateButton.setText(template.isTestPlan() 
+                ? JMeterUtils.getResString("template_create_from")
+                : JMeterUtils.getResString("template_merge_from") );
     }
 
     /**
diff --git a/xdocs/changes.xml b/xdocs/changes.xml
index 3360c0a..97e9a3f 100644
--- a/xdocs/changes.xml
+++ b/xdocs/changes.xml
@@ -219,6 +219,7 @@
     <li><bug>62821</bug><pr>405</pr>Use SHA-512 checksums instead of MD5 to verify jar downloads</li>
     <li><bug>63053</bug>Remove referrals to never implemented internals from user documentation. Reported by U. Poblotzki (u.poblotzki at thalia.de)</li>
     <li><bug>63082</bug><pr>437</pr>Use utf-8 for properties files in source</li>
+    <li><bug>63177</bug>Rename NON GUI mode into CLI Mode in documentation</li>
 </ul>
 
  <!-- =================== Bug fixes =================== -->
@@ -300,6 +301,7 @@
     <li><bug>63099</bug>Escape commata in function helper dialog only outside of variable replacement structures.</li>
     <li><bug>63105</bug>Export Transactions for Report: fix 2 bugs</li>
     <li><bug>63106</bug>Apply naming policy does not refresh UI</li>
+    <li><bug>63180</bug>Apply Naming Policy allows multi selection but only considers first node</li>
     <li><bug>63090</bug>Remove slf4j-ext due to CVE-2018-8088</li>
 </ul>
 
@@ -335,11 +337,6 @@
 
 <ch_section>Known problems and workarounds</ch_section>
 <ul>
-<li>View Results Tree may freeze rendering large response particularly if this response has no spaces, see <bugzilla>60816</bugzilla>.
-This is due to an identified Java Bug <a href="https://bugs.openjdk.java.net/browse/JDK-8172336">UI stuck when calling <code>JEditorPane.setText()</code> or <code>JTextArea.setText()</code> with long text without space</a>.
-</li>
-</ul>
-<ul>
 <li>The Once Only controller behaves correctly under a Thread Group or Loop Controller,
 but otherwise its behaviour is not consistent (or clearly specified).</li>
 
diff --git a/xdocs/images/screenshots/changes/5.1/jdbc-connection-config-init-request.png b/xdocs/images/screenshots/changes/5.1/jdbc-connection-config-init-request.png
index 182c63a..bfe1e23 100644
--- a/xdocs/images/screenshots/changes/5.1/jdbc-connection-config-init-request.png
+++ b/xdocs/images/screenshots/changes/5.1/jdbc-connection-config-init-request.png
Binary files differ
diff --git a/xdocs/index.xml b/xdocs/index.xml
index 1255b3d..bfd40c6 100644
--- a/xdocs/index.xml
+++ b/xdocs/index.xml
@@ -57,7 +57,7 @@
         </ul>
     </li>
     <li>Full featured Test IDE that allows fast Test Plan <b>recording (from Browsers or native applications), building and debugging</b>.</li>
-    <li><b><a href="usermanual/get-started.html#non_gui">Command-line mode (Non GUI / headless mode)</a></b> to load test from any Java compatible OS (Linux, Windows, Mac OSX, &hellip;)</li>
+    <li><b><a href="usermanual/get-started.html#non_gui">CLI mode (Command-line mode (previously called Non GUI) / headless mode)</a></b> to load test from any Java compatible OS (Linux, Windows, Mac OSX, &hellip;)</li>
     <li>A complete and <b><a href="usermanual/generating-dashboard.html" >ready to present dynamic HTML report</a></b></li>
     <li>Easy correlation through ability to extract data from most popular response formats, <b><a href="usermanual/component_reference.html#CSS/JQuery_Extractor" >HTML</a>, <a href="usermanual/component_reference.html#JSON_Extractor" >JSON </a>, 
         <a href="usermanual/component_reference.html#XPath_Extractor" >XML</a> or <a href="usermanual/component_reference.html#Regular_Expression_Extractor" >any textual format</a></b></li>
diff --git a/xdocs/usermanual/best-practices.xml b/xdocs/usermanual/best-practices.xml
index 133e395..ce795b6 100644
--- a/xdocs/usermanual/best-practices.xml
+++ b/xdocs/usermanual/best-practices.xml
@@ -45,7 +45,7 @@
 run with JMeter.  The number will also depend on how fast your server is (a faster server
  makes JMeter work harder since it returns a response quicker).  As with any Load Testing tool, if you don't correctly size
  the number of threads, you will face the "Coordinated Omission" problem which can give you wrong or inaccurate results.
- If you need large-scale load testing, consider running multiple non-GUI JMeter instances on multiple machines 
+ If you need large-scale load testing, consider running multiple CLI JMeter instances on multiple machines 
  using distributed mode (or not). When using distributed mode the result file is combined on the Controller node, if
  using multiple autonomous instances, the sample result files can be combined for subsequent analysis.
 For testing how JMeter performs on a given platform, the JavaTest sampler can be used.
@@ -150,7 +150,7 @@
 Some suggestions on reducing resource usage.
 </p>
 <ul>
-<li>Use non-GUI mode: <code>jmeter -n -t test.jmx -l test.jtl</code></li>
+<li>Use CLI mode: <code>jmeter -n -t test.jmx -l test.jtl</code></li>
 <li>Use as few Listeners as possible; if using the <code>-l</code> flag as above they can all be deleted or disabled.</li>
 <li>Don't use "View Results Tree" or "View Results in Table" listeners during the load test, use them only during scripting phase to debug your scripts.</li>
 <li>Rather than using lots of similar samplers,
@@ -230,7 +230,7 @@
 </source>
 </p>
 <p>
-As a practical example, assume you have a long-running JMeter test running in non-GUI mode,
+As a practical example, assume you have a long-running JMeter test running in CLI mode,
 and you want to vary the throughput at various times during the test.
 The test-plan includes a Constant Throughput Timer which is defined in terms of a property,
 e.g. <code>${__P(throughput)}</code>.
@@ -354,7 +354,7 @@
 To run the test with 20 loops, just change the value of the <code>LOOPS</code> variable on the Test Plan.
 </p>
 <p>
-This quickly becomes tedious if you want to run lots of tests in non-GUI mode.
+This quickly becomes tedious if you want to run lots of tests in CLI mode.
 One solution to this is to define the Test Plan variable in terms of a property,
 for example <code>LOOPS=${__P(loops,10)}</code>.
 This uses the value of the property "<code>loops</code>", defaulting to <code>10</code> if the property is not found.
diff --git a/xdocs/usermanual/boss.xml b/xdocs/usermanual/boss.xml
index 2b6e245..404d413 100644
--- a/xdocs/usermanual/boss.xml
+++ b/xdocs/usermanual/boss.xml
@@ -104,7 +104,7 @@
 <p>
 Also note that some Linux/Unix editions are intended for server use.
 These generally have minimal or no GUI support.
-Such OSes should be OK for running JMeter in non-GUI mode, but JMeter GUI mode probably won't work
+Such OSes should be OK for running JMeter in CLI mode, but JMeter GUI mode probably won't work
 unless you install a minimal GUI environment.
 </p>
 <p>As you progress to larger-scale benchmarks/load-tests, this platform
@@ -116,10 +116,10 @@
 JMeter can easily be installed on Cloud instances as it runs on nearly any architecture available in the Cloud.
 JMeter is also supported within Commercial Cloud PAAS if you don't want to manage it yourself. 
 </p>
-<p>Don't forget JMeter batch (NON-GUI) mode. This mode should be used during load testing for many reasons:
+<p>Don't forget JMeter batch (CLI) mode. This mode should be used during load testing for many reasons:
 <ul>
 <li>If you have a powerful server that supports Java but perhaps does not have a fast graphics implementation, or where you need to login remotely.</li>
-<li>Batch (non-GUI) mode can reduce the network traffic compared with using a remote display or client-server mode.</li>
+<li>Batch (CLI) mode can reduce the network traffic compared with using a remote display or client-server mode.</li>
 <li>Java AWT Thread used for GUI mode can alter injection behaviour by blocking sometimes</li>
 </ul>
 The batch log file can then be loaded into JMeter on a workstation for analysis, or you can
diff --git a/xdocs/usermanual/build-test-plan.xml b/xdocs/usermanual/build-test-plan.xml
index 6bb87d1..5e2abd9 100644
--- a/xdocs/usermanual/build-test-plan.xml
+++ b/xdocs/usermanual/build-test-plan.xml
@@ -89,7 +89,7 @@
 The numbers to the left of the green box are the number of active threads / total number of threads.
 These only apply to a locally run test; they do not include any threads started on remote systems when using client-server mode.
 </p>
-<note>Using GUI mode as described here should only be used when debugging your Test Plan. To run the real load test, use NON-GUI mode.</note>
+<note>Using GUI mode as described here should only be used when debugging your Test Plan. To run the real load test, use CLI mode.</note>
 </subsection>
 
 <subsection name="&sect-num;.6 Stopping a Test" anchor="stop">
@@ -111,8 +111,8 @@
 If Shutdown is taking too long. Close the Shutdown dialog box and select <code>Run</code>/<code>Stop</code>, or just press <keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
 </p>
 <p>
-When running JMeter in non-GUI mode, there is no Menu, and JMeter does not react to keystrokes such as <keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
-So JMeter non-GUI mode will listen for commands on a specific port (default <code>4445</code>, see the JMeter property <code>jmeterengine.nongui.port</code>).
+When running JMeter in CLI mode, there is no Menu, and JMeter does not react to keystrokes such as <keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
+So JMeter CLI mode will listen for commands on a specific port (default <code>4445</code>, see the JMeter property <code>jmeterengine.nongui.port</code>).
 JMeter supports automatic choice of an alternate port if the default port is being used 
 (for example by another JMeter instance). In this case, JMeter will try the next higher port, continuing until
 it reaches the JMeter property <code>jmeterengine.nongui.maxport</code>) which defaults to <code>4455</code>.
diff --git a/xdocs/usermanual/component_reference.xml b/xdocs/usermanual/component_reference.xml
index 01818dd..d5a974a 100644
--- a/xdocs/usermanual/component_reference.xml
+++ b/xdocs/usermanual/component_reference.xml
@@ -1758,7 +1758,7 @@
 The "<code>Stop Now</code>" action stops the test without waiting for samples to complete; it will interrupt any active samples.
 If some threads fail to stop within the 5 second time-limit, a message will be displayed in GUI mode.
 You can try using the <code>Stop</code> command to see if this will stop the threads, but if not, you should exit JMeter.
-In non-GUI mode, JMeter will exit if some threads fail to stop within the 5 second time limit.
+In CLI mode, JMeter will exit if some threads fail to stop within the 5 second time limit.
 <note>The time to wait can be changed using the JMeter property <code>jmeterengine.threadstop.wait</code>. The time is given in milliseconds.</note>
 </p>
 </description>
@@ -2570,9 +2570,9 @@
 Storing as CSV is the most efficient option, but is less detailed than XML (the other available option).
 </p>
 <p>
-<b>Listeners do <i>not</i> process sample data in non-GUI mode, but the raw data will be saved if an output
+<b>Listeners do <i>not</i> process sample data in CLI mode, but the raw data will be saved if an output
 file has been configured.</b>
-In order to analyse the data generated by a non-GUI test run, you need to load the file into the appropriate
+In order to analyse the data generated by a CLI run, you need to load the file into the appropriate
 Listener.
 </p>
 <note>
@@ -2974,7 +2974,7 @@
 <description>This listener can record results to a file
 but not to the UI.  It is meant to provide an efficient means of
 recording data by eliminating GUI overhead.
-When running in non-GUI mode, the <code>-l</code> flag can be used to create a data file.
+When running in CLI mode, the <code>-l</code> flag can be used to create a data file.
 The fields to save are defined by JMeter properties.
 See the <code>jmeter.properties</code> file for details.
 </description>
@@ -3266,7 +3266,7 @@
 See <code>jmeter.properties</code> file for the summariser configuration items:
 <source>
 # Define the following property to automatically start a summariser with that name
-# (applies to non-GUI mode only)
+# (applies to CLI mode only)
 #summariser.name=summary
 #
 # interval between summaries (in seconds) default 3 minutes
@@ -3278,7 +3278,7 @@
 # Write messages to System.out
 #summariser.out=true
 </source>
-This element is mainly intended for batch (non-GUI) runs.
+This element is mainly intended for batch (CLI) runs.
 The output looks like the following:
 <source>
 label +     16 in 0:00:12 =    1.3/s Avg:  1608 Min:  1163 Max:  2009 Err:     0 (0.00%) Active: 5 Started: 5 Finished: 0
@@ -3324,7 +3324,7 @@
 by using suitable labels and adding the summarisers to appropriate parts of the test plan.
 </p>
 <note>
-In Non-GUI mode by default a Generate Summary Results listener named "<code>summariser</code>" is configured, if you have already added one to your Test Plan, ensure you name it differently 
+In CLI mode by default a Generate Summary Results listener named "<code>summariser</code>" is configured, if you have already added one to your Test Plan, ensure you name it differently 
 otherwise results will be accumulated under this label (summary) leading to wrong results (sum of total samples + samples located under the Parent of Generate Summary Results listener).<br/>
 This is not a bug but a design choice allowing to summarize across thread groups.
 </note>
diff --git a/xdocs/usermanual/get-started.xml b/xdocs/usermanual/get-started.xml
index 3d5fccd..4be7598 100644
--- a/xdocs/usermanual/get-started.xml
+++ b/xdocs/usermanual/get-started.xml
@@ -60,9 +60,9 @@
     <li><b>Increase the Java Heap size</b>. By default JMeter runs with a heap of 1 GB, this might not be enough for your test and depends on your test plan and number of threads you want to run</li>
 </ul> 
 
-Once everything is ready, you will use Command-line mode (called <a href="#non_gui">Non-GUI mode</a>) to run it for the Load Test. 
+Once everything is ready, you will use CLI mode (Command-line mode previously called <a href="#non_gui">Non-GUI mode</a>) to run it for the Load Test. 
 <note>Don't run load test using GUI mode !</note><br/>
-Using Non-GUI mode, you can generate a CSV (or XML) file containing results and have JMeter <a href="generating-dashboard.html">generate an HTML report</a> at end of Load Test.
+Using CLI mode, you can generate a CSV (or XML) file containing results and have JMeter <a href="generating-dashboard.html">generate an HTML report</a> at end of Load Test.
 JMeter will by default provide a summary of load test while it's running. <br/>
 You can also have <a href="realtime-results.html" >real-time results</a> during your test using <a href="component_reference.html#Backend_Listener">Backend Listener</a>.
 </p>
@@ -235,7 +235,7 @@
 <p>To run JMeter, run the <code>jmeter.bat</code> (for Windows) or <code>jmeter</code> (for Unix) file.
 These files are found in the <code>bin</code> directory.
 After a short time, the JMeter GUI should appear.
-<note>GUI mode should only be used for creating the test script, NON GUI mode must be used for load testing</note>
+<note>GUI mode should only be used for creating the test script, CLI mode (NON GUI) must be used for load testing</note>
 </p>
 
 <p>
@@ -245,13 +245,13 @@
 <dl>
 <dt><code>jmeter.bat</code></dt><dd>run JMeter (in GUI mode by default)</dd>
 <dt><code>jmeterw.cmd</code></dt><dd>run JMeter without the windows shell console (in GUI mode by default)</dd>
-<dt><code>jmeter-n.cmd</code></dt><dd>drop a JMX file on this to run a non-GUI test</dd>
-<dt><code>jmeter-n-r.cmd</code></dt><dd>drop a JMX file on this to run a non-GUI test remotely</dd>
+<dt><code>jmeter-n.cmd</code></dt><dd>drop a JMX file on this to run a CLI mode test</dd>
+<dt><code>jmeter-n-r.cmd</code></dt><dd>drop a JMX file on this to run a CLI mode test remotely</dd>
 <dt><code>jmeter-t.cmd</code></dt><dd>drop a JMX file on this to load it in GUI mode</dd>
 <dt><code>jmeter-server.bat</code></dt><dd>start JMeter in server mode</dd>
-<dt><code>mirror-server.cmd</code></dt><dd>runs the JMeter Mirror Server in non-GUI mode</dd>
-<dt><code>shutdown.cmd</code></dt><dd>Run the Shutdown client to stop a non-GUI instance gracefully</dd>
-<dt><code>stoptest.cmd</code></dt><dd>Run the Shutdown client to stop a non-GUI instance abruptly</dd>
+<dt><code>mirror-server.cmd</code></dt><dd>runs the JMeter Mirror Server in CLI mode</dd>
+<dt><code>shutdown.cmd</code></dt><dd>Run the Shutdown client to stop a CLI mode instance gracefully</dd>
+<dt><code>stoptest.cmd</code></dt><dd>Run the Shutdown client to stop a CLI mode instance abruptly</dd>
 </dl>
 <note>The special name <code>LAST</code> can be used with <code>jmeter-n.cmd</code>, <code>jmeter-t.cmd</code> and <code>jmeter-n-r.cmd</code>
 and means the last test plan that was run interactively.</note>
@@ -295,9 +295,9 @@
 <dt><code>jmeter</code></dt><dd>run JMeter (in GUI mode by default). Defines some JVM settings which may not work for all JVMs.</dd>
 <dt><code>jmeter-server</code></dt><dd>start JMeter in server mode (calls jmeter script with appropriate parameters)</dd>
 <dt><code>jmeter.sh</code></dt><dd>very basic JMeter script (You may need to adapt JVM options like memory settings).</dd>
-<dt><code>mirror-server.sh</code></dt><dd>runs the JMeter Mirror Server in non-GUI mode</dd>
-<dt><code>shutdown.sh</code></dt><dd>Run the Shutdown client to stop a non-GUI instance gracefully</dd>
-<dt><code>stoptest.sh</code></dt><dd>Run the Shutdown client to stop a non-GUI instance abruptly</dd>
+<dt><code>mirror-server.sh</code></dt><dd>runs the JMeter Mirror Server in CLI mode</dd>
+<dt><code>shutdown.sh</code></dt><dd>Run the Shutdown client to stop a CLI mode instance gracefully</dd>
+<dt><code>stoptest.sh</code></dt><dd>Run the Shutdown client to stop a CLI mode instance abruptly</dd>
 </dl>
 <p>
 It may be necessary to set a few environment variables to configure the JVM used by JMeter. Those variables can be either set directly in the shell starting the <code>jmeter</code> script. For example setting the variable <code>JVM_ARGS</code> will override most pre-defined settings, for example
@@ -443,11 +443,11 @@
 This is not to be confused with the proxy settings described above, which are used when JMeter makes HTTP or HTTPS requests itself.</note>
 </subsection>
 
-<subsection name="&sect-num;.4.4 Non-GUI Mode (Command Line mode)" anchor="non_gui">
+<subsection name="&sect-num;.4.4 CLI Mode (Command Line mode was called NON GUI mode)" anchor="non_gui">
 <p>For load testing, you must run JMeter in this mode (Without the GUI) to get the optimal results from it. To do so, use
 the following command options:</p>
 <dl>
-<dt><code>-n</code></dt><dd>This specifies JMeter is to run in non-gui mode</dd>
+<dt><code>-n</code></dt><dd>This specifies JMeter is to run in cli mode</dd>
 <dt><code>-t</code></dt><dd>[name of JMX file that contains the Test Plan].</dd>
 <dt><code>-l</code></dt><dd>[name of JTL file to log sample results to].</dd>
 <dt><code>-j</code></dt><dd>[name of JMeter run log file].</dd>
@@ -473,7 +473,7 @@
 
 <subsection name="&sect-num;.4.5 Server Mode" anchor="server">
 <p>For <a href="remote-test.html">distributed testing</a>, run JMeter in server mode on the remote node(s), and then control the server(s) from the GUI.
-You can also use non-GUI mode to run remote tests.
+You can also use CLI mode to run remote tests.
 To start the server(s), run <code>jmeter-server[.bat]</code> on each server host.</p>
 <p>The script also lets you specify the optional firewall/proxy server information:</p>
 <dl>
@@ -484,7 +484,7 @@
 <source>jmeter-server -H my.proxy.server -P 8000</source>
 <p>If you want the server to exit after a single test has been run, then define the JMeter property <code>server.exitaftertest=true</code>.
 </p>
-<p>To run the test from the client in non-GUI mode, use the following command:</p>
+<p>To run the test from the client in CLI mode, use the following command:</p>
 <source>
 jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X]
 </source>
@@ -789,7 +789,7 @@
     -d, --homedir &lt;argument&gt;
         the jmeter home directory to use
     -X, --remoteexit
-        Exit the remote servers at end of test (non-GUI)
+        Exit the remote servers at end of test (CLI mode)
     -g, --reportonly &lt;argument&gt;
         generate report dashboard only, from a test results file
     -e, --reportatendofloadtests
@@ -808,9 +808,9 @@
 </p>
 </subsection>
 
-<subsection name="&sect-num;.4.9 non-GUI shutdown" anchor="shutdown">
+<subsection name="&sect-num;.4.9 CLI mode shutdown" anchor="shutdown">
 <p>
-Prior to version 2.5.1, JMeter invoked <code>System.exit()</code> when a non-GUI test completed.
+Prior to version 2.5.1, JMeter invoked <code>System.exit()</code> when a CLI mode test completed.
 This caused problems for applications that invoke JMeter directly, so JMeter no longer invokes <code>System.exit()</code>
 for a normal test completion. [Some fatal errors may still invoke <code>System.exit()</code>]
 JMeter will exit all the non-daemon threads it starts, but it is possible that some non-daemon threads
diff --git a/xdocs/usermanual/index.xml b/xdocs/usermanual/index.xml
index 3854cd5..f47e2ae 100644
--- a/xdocs/usermanual/index.xml
+++ b/xdocs/usermanual/index.xml
@@ -89,12 +89,12 @@
         <li><a href="get-started.html#classpath">1.4.1 JMeter's Classpath</a></li>
         <li><a href="get-started.html#template">1.4.2 Create Test Plan from Template</a></li>
         <li><a href="get-started.html#proxy_server">1.4.3 Using JMeter behind a proxy</a></li>
-        <li><a href="get-started.html#non_gui">1.4.4 Non-GUI Mode</a></li>
+        <li><a href="get-started.html#non_gui">1.4.4 CLI mode</a></li>
         <li><a href="get-started.html#server">1.4.5 Server Mode</a></li>
         <li><a href="get-started.html#override">1.4.6 Overriding Properties Via The Command Line</a></li>
         <li><a href="get-started.html#logging">1.4.7 Logging and Error Messages</a></li>
         <li><a href="get-started.html#options">1.4.8 Full list of command-line options</a></li>
-        <li><a href="get-started.html#shutdown">1.4.9 non-GUI shutdown</a></li>
+        <li><a href="get-started.html#shutdown">1.4.9 CLI mode shutdown</a></li>
      </ul>
      </li>
      <li><a href="get-started.html#configuring_jmeter">1.5 Configuring JMeter</a></li>
diff --git a/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml b/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
index af77a18..0465f96 100644
--- a/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
+++ b/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
@@ -51,7 +51,7 @@
 have JMeter installed on all the systems. The way JMeter works is one master controller initiates the test on multiple slave systems.
 </p>
 
-<note>In this tutorial we use GUI Mode just for demonstration. In real life you should use NON GUI mode to start your load test</note>
+<note>In this tutorial we use GUI Mode just for demonstration. In real life you should use CLI mode (NON GUI) to start your load test</note>
 
 <figure width="610" height="462" image="distributed-jmeter.svg">One master controls multiple slaves</figure>
 
diff --git a/xdocs/usermanual/jmeter_proxy_step_by_step.xml b/xdocs/usermanual/jmeter_proxy_step_by_step.xml
index 12539ef..1d17257 100644
--- a/xdocs/usermanual/jmeter_proxy_step_by_step.xml
+++ b/xdocs/usermanual/jmeter_proxy_step_by_step.xml
@@ -205,7 +205,7 @@
 
 
 <p>
-Solution 1, with the gui, but just during debug phase, use Non GUI for your load test.
+Solution 1, with the gui, but just during debug phase, use CLI mode (Non GUI) for your load test.
 </p>
 <p>
   <menuchoice>
diff --git a/xdocs/usermanual/listeners.xml b/xdocs/usermanual/listeners.xml
index 0cc7def..48e4fc5 100644
--- a/xdocs/usermanual/listeners.xml
+++ b/xdocs/usermanual/listeners.xml
@@ -69,7 +69,7 @@
 <p>
 The default items to be saved can be defined in the <code>jmeter.properties</code> (or <code>user.properties</code>) file.
 The properties are used as the initial settings for the Listener Config pop-up, and are also
-used for the log file specified by the <code>-l</code> command-line flag (commonly used for non-GUI test runs).
+used for the log file specified by the <code>-l</code> command-line flag (commonly used for CLI mode test runs).
 </p>
 <p>To change the default format, find the following line in <code>jmeter.properties</code>:</p>
 <source>jmeter.save.saveservice.output_format=</source>
@@ -237,9 +237,9 @@
 </p>
 </section>
 
-<section name="&sect-num;.2 non-GUI (batch) test runs" anchor="batch">
+<section name="&sect-num;.2 CLI mode (batch) test runs" anchor="batch">
 <p>
-When running in non-GUI mode, the <code>-l</code> flag can be used to create a top-level listener for the test run.
+When running in CLI mode, the <code>-l</code> flag can be used to create a top-level listener for the test run.
 This is in addition to any Listeners defined in the test plan.
 The configuration of this listener is controlled by entries in the file <code>jmeter.properties</code>
 as described in the previous section.
diff --git a/xdocs/usermanual/properties_reference.xml b/xdocs/usermanual/properties_reference.xml
index 66caa73..d578a17 100644
--- a/xdocs/usermanual/properties_reference.xml
+++ b/xdocs/usermanual/properties_reference.xml
@@ -1066,12 +1066,12 @@
     Defaults to: <code>2</code></property>
 </properties>
 </section>
-<section name="&sect-num;.26 Summariser - Generate Summary Results - configuration (mainly applies to non-GUI mode)" anchor="summariser">
+<section name="&sect-num;.26 Summariser - Generate Summary Results - configuration (mainly applies to CLI mode)" anchor="summariser">
 <properties>
 <property name="summariser.name">
-    Comment the following property to disable the default non-GUI summariser.<br/>
+    Comment the following property to disable the default CLI mode summariser.<br/>
     [or change the value to rename it]<br/>
-    <note>Applies to non-GUI mode only</note>
+    <note>Applies to CLI mode only</note>
     Defaults to: <code>summary</code>
 </property>
 <property name="summariser.interval">
@@ -1409,14 +1409,13 @@
     Defaults to: <code>false</code>
 </property>
 <property name="jmeterengine.stopfail.system.exit">
-    Whether to call <code>System.exit(1)</code> on failure to stop threads in
-    non-GUI mode.<br/>
+    Whether to call <code>System.exit(1)</code> on failure to stop threads in CLI mode.<br/>
     This only takes effect if the test was explicitly requested to stop.<br/>
     If this is disabled, it may be necessary to kill the JVM externally.<br/>
     Defaults to: <code>true</code>
 </property>
 <property name="jmeterengine.force.system.exit">
-    Whether to force call <code>System.exit(0)</code> at end of test in non-GUI mode,
+    Whether to force call <code>System.exit(0)</code> at end of test in CLI mode,
     even if there were no failures and the test was not explicitly asked to stop.<br/>
     Without this, the JVM may never exit if there are other threads spawned by
     the test which never exit.<br/>
@@ -1429,7 +1428,7 @@
     Defaults to: <code>2000</code>
 </property>
 <property name="jmeterengine.nongui.port">
-    If running non-GUI, then JMeter listens on the following port for a shutdown message.<br/>
+    If running CLI mode, then JMeter listens on the following port for a shutdown message.<br/>
     To disable, set the port to <code>1000</code> or less.<br/>
     Defaults to: <code>4445</code>
 </property>
@@ -1543,7 +1542,7 @@
 </property>
 <property name="classfinder.functions.contain">
     The classpath finder currently needs to load every single JMeter class to find the classes it needs.<br/>
-    For non-GUI mode, it's only necessary to scan for Function classes, but all classes are still loaded.<br/>
+    For CLI mode, it's only necessary to scan for Function classes, but all classes are still loaded.<br/>
     All current Function classes include "<code>.function.</code>" in their name, and none include
     "<code>.gui.</code>" in the name, so the number of unwanted classes loaded can be reduced by
     checking for these. However, if a valid function class name does not match these restrictions,
diff --git a/xdocs/usermanual/remote-test.xml b/xdocs/usermanual/remote-test.xml
index 00114b5..6b72f5f 100644
--- a/xdocs/usermanual/remote-test.xml
+++ b/xdocs/usermanual/remote-test.xml
@@ -50,7 +50,7 @@
 So if you set 1000 Threads and have 6 JMeter server, you end up injecting 6000 Threads.
 </note>
 <p>
-However, remote mode does use more resources than running the same number of non-GUI tests independently.
+However, remote mode does use more resources than running the same number of CLI mode tests independently.
 If many server instances are used, the client JMeter can become overloaded, as can the client network connection.
 This has been improved by switching to Stripped modes (see below) but you should always check that your client is not overloaded.
 </p>
@@ -114,9 +114,9 @@
 normal JMeter start and stop menu items.</p>
 <figure image="remote/run-menu00.png" width="487" height="295">Figure 1 - Run Menu</figure>
 
-<p><b>Step 3b: Start the JMeter from a non-GUI Client</b></p>
+<p><b>Step 3b: Start the JMeter from a CLI mode Client</b></p>
 <p>
-GUI mode should only be used for debugging, as a better alternative, you should start the test on remote server(s) from a non-GUI (command-line) client.
+GUI mode should only be used for debugging, as a better alternative, you should start the test on remote server(s) from a CLI mode (command-line) client.
 The command to do this is:</p>
 <source>
 jmeter -n -t script.jmx -r