Release XLT 5.1.1

Merge remote-tracking branch 'remotes/origin/develop'

doc/xltdoc/_drafts/faq.textile

@@ -88,7 +88,7 @@ When you look into the directory for temporary files, you might find some files
 
 h5. htmlunit*.tmp
 
-When HtmlUnit - the underlying HTML test framework used by XLT - downloads the response body of a HTTP request it first checks if its size is greater than 500kB. In this case, the response body is written to disk instead of keeping it in memory.
+When HtmlUnit - the underlying HTML test framework used by XLT - downloads the response body of an HTTP request it first checks if its size is greater than 500kB. In this case, the response body is written to disk instead of keeping it in memory.
 
 When the Java Virtual Machine terminates normally, all those files will be deleted. In case of abnormal termination, some or all of these files might not be deleted.
 

doc/xltdoc/_drafts/showcases.textile

@@ -77,9 +77,9 @@ p. To handle PDFs you have to include an additional library. We provide samples
 
 h4. Test case: _TPdfContentSearch_itext_
 
-p. This test case demonstates how to search in a PDF file for a certain word using the iText library. We take the PDF file and search on each page sequentially.
+p. This test case demonstrates how to search in a PDF file for a certain word using the iText library. We take the PDF file and search on each page sequentially.
 
-h4. Test case: _TPdfContenSearch_pdfbox_
+h4. Test case: _TPdfContentSearch_pdfbox_
 
 p. The same example using the PDFbox library. 
 
@@ -91,7 +91,7 @@ h4. Test case: _TPopup_
 
 p. In this test case we learn how to handle a popup. The test case page contains a button that opens a popup. In this popup, we enter a text and press apply. This transfers the text to the start page and closes the popup.
 
-p. Afterwards we load a page with a onload popup. We show how to work with the different WebWindows and close the popup at the end.
+p. Afterwards we load a page with an onload popup. We show how to work with the different WebWindows and close the popup at the end.
 
 h3. Prompt
 

doc/xltdoc/_layouts/how-to.html

@@ -8,7 +8,7 @@
     {% include header.html level=2 %}
 
     <div class="main">
-		  <div clas="row">
+		  <div class="row">
 			<div id="content" class="col-md-9">			
 				{{ content }}
 				{% include footer.html %}

doc/xltdoc/getting-started/01-test-automation.textile

@@ -89,7 +89,7 @@ p. Follow the steps below to create a script test suite for the _Posters_ shop,
 # Start Script Developer
 ** Click 'Tools | XLT Script Developer' from Firefox menu
 
-p(illustration). !../img/quickstart/QuickStart_StartScriptDevloper-small.png(Start Script Developer)!:../img/quickstart/QuickStart_StartScriptDevloper.png
+p(illustration). !../img/quickstart/QuickStart_StartScriptDeveloper-small.png(Start Script Developer)!:../img/quickstart/QuickStart_StartScriptDeveloper.png
 
 #_ Create Script Test Suite
 ** Confirm notice 'There is currently no test suite directory configured.' with OK
@@ -111,13 +111,13 @@ p(illustration). !../img/quickstart/QuickStart_TestCaseDetails-small.png(Test Ca
 
 #_ Start Recording
 ** Open a new tab in Firefox and load the first page you want to record on
-** Click 'Record' button in the XLT Script Devloper or press <kbd>Alt</kbd>+<kbd>F9</kbd> to start recording user interactions and validations on the page
+** Click 'Record' button in the XLT Script Developer or press <kbd>Alt</kbd>+<kbd>F9</kbd> to start recording user interactions and validations on the page
 ** To record user interactions just perform them in the open browser tab, e.g. click links, open dropdown boxes, fill and submit forms etc.
 
 p(illustration). !../img/quickstart/QuickStart_StartRecording-small.png(Start Recording)!:../img/quickstart/QuickStart_StartRecording.png
 
 #_ Add Validation Steps
-** Because XLT Script Developer is all about testing you should definitly add checks to validate that the expected page elements are present at the correct positions, headlines and page titles are correct and so on. We call them validation steps or assertions
+** Because XLT Script Developer is all about testing you should definitely add checks to validate that the expected page elements are present at the correct positions, headlines and page titles are correct and so on. We call them validation steps or assertions
 ** You can add validation steps at any time during recording a test case script by using the browsers context menu
 ** Right-click on a page element and select one of the available assert... or waitFor... commands from the context menu 'XLT Script Developer'
 

doc/xltdoc/getting-started/02-performance-testing.textile

@@ -59,7 +59,7 @@ To get rid of the displayed build errors for our test suite we have to add the X
 # Right-click on the project name and select _Properties_
 # In the properties dialog select _Java Build Path_ on the left side
 # Select the _Libraries_ tab and click button _Add External JARs..._
-# In the _JAR selection_ dialog browse to the XLT installation directory. Got to @<xlt>/lib@ sub-directory and and select all files in there (e.g. press <kbd>Ctrl</kbd>+<kbd>A</kbd>).
+# In the _JAR selection_ dialog browse to the XLT installation directory. Got to @<xlt>/lib@ sub-directory and select all files in there (e.g. press <kbd>Ctrl</kbd>+<kbd>A</kbd>).
 # Confirm by clicking OK in both of the opened dialogs
 
 p(illustration). !../img/quickstart/QuickStart_AddLibs-small.png(Add XLT Libraries to Test Suite)!:../img/quickstart/QuickStart_AddLibs.png
@@ -127,7 +127,7 @@ com.xceptance.xlt.loadtests.TBrowse.users = 3
 com.xceptance.xlt.loadtests.TSearch.users = 1
 com.xceptance.xlt.loadtests.TOrder.measurementPeriod = 5m
 
-bq(note). XLT is completly free for any functional testing whereas load testing with more than 5 concurrent virtual users requires a "license":https://www.xceptance.com/en/xlt/licensing-and-pricing.html. All of the examples in this document are limited to 5 virtual users to be able to run without a license.
+bq(note). XLT is completely free for any functional testing whereas load testing with more than 5 concurrent virtual users requires a "license":https://www.xceptance.com/en/xlt/licensing-and-pricing.html. All of the examples in this document are limited to 5 virtual users to be able to run without a license.
 
 
 h2. Run the Load Test

doc/xltdoc/how-to/basic-rules-for-test-suite.textile

@@ -52,7 +52,7 @@ you should better use something like @//div[@id='cart']/div[1]@. XLT Script Deve
 
 h3. Do not let your test cases end with a clickAndWait command!
 
-p. In the context of test automation this doesn't make sense without any validation/assertions. For example, in most cases it is not necessary to close dialog windows or returning back to start page at the end of the script. If you want to check if e.g. a 'Back' button is existing then it is enough to validate this and that's it. You don't need to click it. This can save significant time during test execution because it saves you a lot of page loads. If it is necessary to check if returning to home page works as expected, then you have to add some assertions after the last clicAndWait command.
+p. In the context of test automation this doesn't make sense without any validation/assertions. For example, in most cases it is not necessary to close dialog windows or returning back to start page at the end of the script. If you want to check if e.g. a 'Back' button is existing then it is enough to validate this and that's it. You don't need to click it. This can save significant time during test execution because it saves you a lot of page loads. If it is necessary to check if returning to home page works as expected, then you have to add some assertions after the last clickAndWait command.
 
 p. There are exceptions from this rule of course (_let your test cases end with a clickAndWait command!_): If you clean up, then clicking a 'Delete' button as the last command could make sense. Also if it's necessary to log-out, then clicking the log-out link as the last command is acceptable. But again: Why not add an assertion that makes sure that you were successful with that click?
 

doc/xltdoc/how-to/criteria-validation-tool.textile

@@ -40,7 +40,7 @@ bc(json). {
       "id": "NoRequestErrors",
       "enabled": true,
       "condition": "not(//request/errors/*[number() > 0]",
-      "message": "Errorneous requests encountered" 
+      "message": "Erroneous requests encountered" 
     }
   ]
 }
@@ -97,7 +97,7 @@ bc(json). {
       "id": "NoRequestErrors",
       "enabled": true,
       "condition": "not(//request/errors/*[number() > 0]",
-      "message": "Errorneous requests encountered" 
+      "message": "Erroneous requests encountered" 
     }
   ],
   "checks": [

doc/xltdoc/how-to/importing-XLT-projects-into-eclipse.textile

@@ -10,7 +10,7 @@ lead: How to set up Eclipse to run and debug test suites.
 
 h2. Introduction
 
-A script test suite created with XLT Script Developer is a perfect starting point for all the other great things you can do with the XLT Framework. The example below describes how to run the tests as JUnit tests from within an Java IDE.
+A script test suite created with XLT Script Developer is a perfect starting point for all the other great things you can do with the XLT Framework. The example below describes how to run the tests as JUnit tests from within a Java IDE.
 
 From there it's a waltz to do cross-browser testing or integrate the tests into a continuous integration process. Running the same test suite as a load and performance test or data-driven test is also possible. You can even export the test cases to Java code to add more advanced functionality like handling conditions, execution branches and random factors. For this you can choose from multiple APIs like WebDriver or HtmlUnit - which is great if you're already familiar with one of those.
 

doc/xltdoc/index.html

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: XLT Documentation - Overview
-description: Xceptance LoadTest Documentaion
+description: Xceptance LoadTest Documentation
 
 type: landing
 level: 1

doc/xltdoc/release-notes/5.0.x.textile

@@ -5,47 +5,6 @@ position: 984
 sorted: true
 ---
 
-h2. XLT 5.1.0
-
-See "here":https://github.com/Xceptance/XLT/milestone/3?closed=1 for the complete list of improvements and fixes.
-
-h3. Test Framework
-
-h4. Socket instrumentation fails with Java 13
-
-Load tests could not be run with Java 13 or later as instrumenting the socket layer to gather low-level network measurements failed. This was caused by the new socket implementation in Java 13 which comes with some API changes.
-
-h4. Update 3rd-party libraries
-
-Several 3rd-party libraries, most notably HtmlUnit, have been updated.
-
-
-h3. Load Testing
-
-h4. Agent should search default Gradle classes directories
-
-The XLT agent that executes a load test suite searches several directories inside the uploaded test suite for test classes and libraries. Now this includes the default Gradle classes directories as well. See below for the current list of directories that are searched (in this order) for classes and libraries, respectively.
-
-*Classes Directories*
-
-* @<testsuite>/classes@
-* @<testsuite>/target/classes@ (Maven)
-* @<testsuite>/target/test-classes@ (Maven)
-* @<testsuite>/build/classes/java/main@ (Gradle)
-* @<testsuite>/build/classes/java/test@ (Gradle)
-* @<testsuite>/bin@ (Eclipse)
-
-*Library Directories*
-
-* @<testsuite>/lib@
-* @<testsuite>/target/dependency@ (Maven)
-
-h4. Support new region us-west3 in gce_admin
-
-Google opened a new data center in Salt Lake City, Utah, USA (us-west3). @gce_admin@, our tool to manage machine instances in the Google cloud, now fully supports this new region as well.
-
-
-
 h2. XLT 5.0.1
 
 The main goal of this release was to prepare everything needed so that XLT can be published to "Maven Central":https://search.maven.org/artifact/com.xceptance/xlt. This means that from now on XLT will be hosted there instead of the Xceptance repository. Consequently, you'll no longer need to configure the Xceptance repository in your @pom.xml@:

doc/xltdoc/release-notes/5.1.x.textile

@@ -0,0 +1,69 @@
+---
+layout: manual
+title: 5.1.x
+position: 983
+sorted: true
+---
+
+h2. XLT 5.1.1
+
+See "here":https://github.com/Xceptance/XLT/milestone/4?closed=1 for the complete list of improvements and fixes.
+
+h3. Load Testing
+
+h4. ec2_admin and gce_admin support new cloud regions
+
+Recently, Amazon and Google opened new data centers:
+
+* Amazon:
+** Milan, Italy, Europe (eu-south-1)
+** Cape Town, South Africa, Africa (af-south-1)
+* Google:
+** Las Vegas, Nevada, USA (us-west4)
+
+These regions are now supported in @ec2_admin@  and @gce_admin@, respectively.
+
+h4. AWS EC2 images updated
+
+Our AWS EC2 machine images with XLT pre-installed are now based on Ubuntu 18.04. We have also updated certain software packages to the latest available version. This includes AdoptOpenJDK, Firefox ESR, and Geckodriver.
+
+
+
+h2. XLT 5.1.0
+
+See "here":https://github.com/Xceptance/XLT/milestone/3?closed=1 for the complete list of improvements and fixes.
+
+h3. Test Framework
+
+h4. Socket instrumentation fails with Java 13
+
+Load tests could not be run with Java 13 or later as instrumenting the socket layer to gather low-level network measurements failed. This was caused by the new socket implementation in Java 13 which comes with some API changes.
+
+h4. Update 3rd-party libraries
+
+Several 3rd-party libraries, most notably HtmlUnit, have been updated.
+
+
+h3. Load Testing
+
+h4. Agent should search default Gradle classes directories
+
+The XLT agent that executes a load test suite searches several directories inside the uploaded test suite for test classes and libraries. Now this includes the default Gradle classes directories as well. See below for the current list of directories that are searched (in this order) for classes and libraries, respectively.
+
+*Classes Directories*
+
+* @<testsuite>/classes@
+* @<testsuite>/target/classes@ (Maven)
+* @<testsuite>/target/test-classes@ (Maven)
+* @<testsuite>/build/classes/java/main@ (Gradle)
+* @<testsuite>/build/classes/java/test@ (Gradle)
+* @<testsuite>/bin@ (Eclipse)
+
+*Library Directories*
+
+* @<testsuite>/lib@
+* @<testsuite>/target/dependency@ (Maven)
+
+h4. Support new region us-west3 in gce_admin
+
+Google opened a new data center in Salt Lake City, Utah, USA (us-west3). @gce_admin@, our tool to manage machine instances in the Google cloud, now fully supports this new region as well.

doc/xltdoc/user-manual/02-install.textile

@@ -14,7 +14,7 @@ h3. Hardware
 h3. Software
 
 * Operating System: Microsoft Windows, Linux, Oracle Solaris, HP-UX, or Mac OS X, that is any operating system for which a JVM 7 (or higher) is available.
-* JVM: It's recommended to use Oracle's JVM. XLT also runs on OpenJDK. JVMs provided by vendors such as OpenJDK BEA, HP, or IBM have not been tested extensivly and may or may not work.
+* JVM: It's recommended to use Oracle's JVM. XLT also runs on OpenJDK. JVMs provided by vendors such as OpenJDK BEA, HP, or IBM have not been tested extensively and may or may not work.
 * Browser: Firefox, Chrome, Internet Explorer 10, or Safari 6 for the HTML load reports. Note that JavaScript has to be enabled to utilize all functionality. If you want to use XLT Script Developer, you need to have Firefox 31 (or higher).
 
 h2. Installing XLT

doc/xltdoc/user-manual/03-scriptdeveloper.textile

@@ -535,7 +535,7 @@ public class TSearch extends AbstractWebDriverScriptTestCase
         assertElementPresent("id=product0");
         // Store the name of the first product
         storeText("css=#product0 .pInfo .pName", "productName");
-        // Click the product ilnk to open the product detail page
+        // Click the product link to open the product detail page
         clickAndWait("css=#product0 img");
         // Validate it's the correct product detail page
         assertText("css=#titleProductName", resolve("${productName}"));
@@ -560,7 +560,7 @@ public class Search extends AbstractWebDriverModule
 		click("id=header-search-trigger");
 		waitForElementPresent("id=header-menu-search");        
 		type("id=s", searchTerm);
-        // Cick the search button to submit
+        // Click the search button to submit
         clickAndWait("id=btnSearch");
     }
 }
@@ -654,7 +654,7 @@ bc(xml).. <?xml version="1.0" encoding="UTF-8"?>
     <parameter name="searchTerm" value="${searchTerm}"/>
   </module>
   <command name="assertElementPresent" target="id=infoMessage">
-    <comment>Assert presence of info maessage element</comment>
+    <comment>Assert presence of info message element</comment>
   </command>
   <command name="assertText" target="xpath=id('infoMessage')/div/strong" value="*Sorry! No results found matching your search. Please try again.*">
     <comment>Validate the 'no results' message</comment>

doc/xltdoc/user-manual/04-framework.textile

@@ -288,7 +288,7 @@ h4. Validators
 
 We strongly encourage you to write individual validation classes for easy reuse. As soon as a certain check has to be done more than once, it is suited for a validator implementation. This simplifies the maintenance of tests and makes them less error-prone because copy-paste causes typical programming errors.
 
-Some common validation routines are already covered by default validators, such as a HTTP response code, HTML end tag, and HTTP content length validation. See package @com.xceptance.xlt.api.validators@ in the API documentation for more information on this topic.
+Some common validation routines are already covered by default validators, such as an HTTP response code, HTML end tag, and HTTP content length validation. See package @com.xceptance.xlt.api.validators@ in the API documentation for more information on this topic.
 
 
 h3. Example

doc/xltdoc/user-manual/08-loadtest.textile

@@ -597,4 +597,4 @@ Both interactive mode and auto mode can be combined with the command line option
 
 This is useful if you want to run load tests without a distributed load test environment, but run just one agent controller together with the master controller on the same machine. There's no need to manually start an agent controller before you run the load test, which facilitates the handling of automated load tests started from within a build process. This option is also recommended when playing around with the "posters demo":07-posters.html for training purposes because it simplifies the process of running a load test.
 
-bq(note). When you use the @-embedded@ option, the local agent controller settings will override the set of agent controllers configured in @mastercontroller.properies@.
+bq(note). When you use the @-embedded@ option, the local agent controller settings will override the set of agent controllers configured in @mastercontroller.properties@.

doc/xltdoc/user-manual/09-reports.textile

@@ -103,7 +103,7 @@ If you click on one of the action names in the navigation, the result browser wi
 ** It starts with the string @image@. In this case change the color to %{color:green}green%.
 ** It is equal to @text/css@. This content type denotes CSS and thus change the color to %{color:blue}blue%.
 
-bq(warning). Please note that the content type is determined by the appropriate HTTP response header value. Thus, if an JavaScript file is delivered as content type @text/plain@ then this request will be color-coded with black.
+bq(warning). Please note that the content type is determined by the appropriate HTTP response header value. Thus, if a JavaScript file is delivered as content type @text/plain@ then this request will be color-coded with black.
 
 When you select one of the requests from the navigation, the page content will be replaced by detailed information about the request and the related response that you can access via the four tabs on top of the page. The following information is available:
 
@@ -226,7 +226,7 @@ If an error occurred during the load test run, the corresponding error message a
 You can also access the result browsers directly from the load test report. This greatly speeds up error analysis because you would just have to click the directory name next to an error entry to open the respective result browser. To make this work, you first need to ensure that:
 
 * the results will be provided at the target location, and
-* the results directory will never be renamed oder moved.
+* the results directory will never be renamed or moved.
 
 Otherwise, viewers of the report experience broken links.