Remove System V init instructions that no longer work

CHANGELOG.md

@@ -198,7 +198,7 @@ Fixed Issues
 
 -   Parameterized trigger from a multi-configuration project triggers
     downstream jobs twice (JENKINS-11669)
--   Allow speciying Git SHA1 commit id for next build(s) as Predefined
+-   Allow specifying Git SHA1 commit id for next build(s) as Predefined
     parameter (JENKINS-13852)
 -   Counter/File Parameter Factories now can prevent triggering, skip
     adding parameteers or fail the build if errors occur.
@@ -254,7 +254,7 @@ Release date: (Feb 9, 2012)
 -   When multiple builds are launched as blocking build steps, all
     should be listed as "waiting to complete", and should be listed in
     launched order. (JENKINS-11116, JENKINS-11117)
--   Fixed a compatibility with hierachical jobs (such as the CloudBees
+-   Fixed a compatibility with hierarchical jobs (such as the CloudBees
     folder plugin.)
 -   Added a mechanism to repeatedly invoke jobs for each file that
     matches GLOB ([pull
@@ -416,7 +416,7 @@ Release date: (Feb 28, 2009)
 
 Release date: (Feb 27, 2009)
 
--   Fixes incompatiblity with Jenkins 1.285. Jenkins 1.286 is a minimum
+-   Fixes incompatibility with Jenkins 1.285. Jenkins 1.286 is a minimum
     requirement for this version.
 
 #### 1.0, 1.1 

README.md

@@ -1,5 +1,4 @@
-Parameterized Trigger Plugin
-============================
+# Parameterized Trigger Plugin
 
 [![Jenkins Plugin](https://img.shields.io/jenkins/plugin/v/parameterized-trigger.svg)](https://plugins.jenkins.io/parameterized-trigger)
 [![GitHub release](https://img.shields.io/github/release/jenkinsci/parameterized-trigger-plugin.svg?label=changelog)](https://github.com/jenkinsci/parameterized-trigger-plugin/releases/latest)
@@ -11,7 +10,7 @@ with various ways of specifying parameters for the new build.
 These new builds appear as "Subprojects" in the Jenkins UI when you
 are looking at a project that triggers them.
 
-You can add multiple configurations: each has a list of projects to trigger, a condition for when to trigger them 
+You can add multiple configurations: each has a list of projects to trigger, a condition for when to trigger them
 (based on the result of the current build), and a parameters section.
 
 There is also a Parameterized Remote Trigger Plugin in case you want to trigger a build on a different/remote Jenkins Controller.
@@ -35,7 +34,7 @@ This lets you create a "function call" like semantics.
 
  #### Usage as a Build step
 
-When using the _Trigger/Call builds on another project_ item.  
+When using the _Trigger/Call builds on another project_ item.
 If the trigger is configured with the "Block until the triggered projects finish their builds" enabled, the following Environment variables are made available for further build steps.
 
 Env variables for future build steps:
@@ -48,87 +47,63 @@ Env variables for future build steps:
 -   `TRIGGERED_BUILD_RESULT_<project name>*RUN*<build number>` - Result of triggered build for build number
 -   `TRIGGERED_BUILD_RUN_COUNT_<project name>` - Number of builds triggered for the project
 
-From 2.17 onwards: All Project names have characters not a-zA-Z or 0-9 replaced by  
-`_(multiple characters are condensed into a single)`.  
+From 2.17 onwards: All Project names have characters not a-zA-Z or 0-9 replaced by
+`_(multiple characters are condensed into a single)`.
 
 Note that with the BuildStep a variable can be used for the project name, I.E. `${projectName}`.
 
-#### Use of the plugin in a Matrix job
+## Use of the plugin in a Matrix job
 
-##### Post build task
+### Post build task
 
-When using the trigger parameterized build as a post build task for a matrix job the triggering will be be done once when all of the different matrix configurations have completed.  
+When using the trigger parameterized build as a post build task for a matrix job the triggering will be be done once when all of the different matrix configurations have completed.
 In this case some of the Environment variables may not be resolvable as passing them to downstream jobs will fail.
 You also cannot use a variable for the downstream project name.
-If this functionality is needed, the BuildStep must be used. 
+If this functionality is needed, the BuildStep must be used.
 
-Environment variables that should be available are the the default shell ones (`<yourserver:port>/env-vars.html`) and ones defined as Parameters.  
+Environment variables that should be available are the the default shell ones (`<yourserver:port>/env-vars.html`) and ones defined as Parameters.
 Variables added by the other plugins as a buildwrappers may not be available.
 
-##### Build step
+### Build step
 
-When using the trigger parameterized build as a buildstep it will be called for every different configuration,
+When using the trigger parameterized build as a build step it will be called for every different configuration,
 so if triggering another project with no parameters it will be done the same number of times as you have configurations,
 possible causing the triggered job to run more than once.
 
 However this also allows you to trigger other jobs with parameters relating to the current configuration,
 i.e. triggering a build on the same node with the same JDK.
 
-#### Plugins contributing additional parameter types to this plugin
+## Plugins contributing additional parameter types to this plugin
 
 * Git Plugin
 * NodeLabel Parameter Plugin
 
-#### Backward compatibility with version 2.22
+## Backward compatibility with version 2.22
 
 -   Since Parameterized Trigger 2.23, there are cases that Parameterized Trigger fails to trigger downstream builds that can be successfully triggered with Parameterized Trigger \<= 2.22.
-    -   This is caused by the new behavir introduced in Parameterized Trigger 2.23.
+    -   This is caused by the new behavior introduced in Parameterized Trigger 2.23.
         It gets to pass parameter values not directly to the downstream build, but to parameter definitions of downstream projects.
-        This enables parameter definitions perform its specific process, for example, selecting nodes with NodeLabel Parameter Plugin.
--   Example: There is a project with a choice parameter with choices A, B, C. 
+        This enables parameter definitions to perform its specific process, for example, selecting nodes with NodeLabel Parameter Plugin.
+-   Example: There is a project with a choice parameter with choices A, B, C.
     When you triggered that project with parameter value D, it fails with following output in the upstream:
 
 ```
     java.lang.IllegalArgumentException: Illegal choice: D at
     hudson.model.ChoiceParameterDefinition.checkValue(ChoiceParameterDefinition.java:72)
 ```
 
--   This is taken as a designated behavior.
+-   This is the intended behavior.
     -   As those failures are ones designed by parameter definitions.
-        For example, the choice parameter is designed not to accept unexpected values.
-    -   You will face same problem when you triggered those builds with Jenkins CLI or Remote access API.
+        For example, the choice parameter is designed to not accept unexpected values.
+    -   The same behavior is visible builds are triggered those with the Jenkins CLI or the remote access API.
 -   It is recommended to fix your project configuration to have parameter definitions not fail.
     -   For example, use EnvInject Plugin to process values or use Extensible Choice Parameter Plugin which provides a choice parameter accepting edited values.
-
-##### Workaround
-
-As backward compatibility, you can make it work without fix by setting Java system property `hudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode` to `true`.
-It can be done with launching Jenkins as followings:
 
-```
-        java -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true -jar jenkins.war
-```
-
-In RedHat Linux systems, you can modify /etc/sysconfig/jenkins as following:
-
-```
-        -JENKINS\_JAVA\_OPTIONS="-Djava.awt.headless=true"
-        +JENKINS\_JAVA\_OPTIONS="-Djava.awt.headless=true -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true"
-```
-In Debian Linux systems, you can modify /etc/defaults/jenkins as following:
+### Workaround
 
-```
-        -JAVA_ARGS="-Djava.awt.headless=true" # Allow graphs etc. to work even when an X server is present
-        +JAVA_ARGS="-Djava.awt.headless=true -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true"
-```
-
-In Windows system, you can modify jenkins.xml placed in the installed folder.
-
-```
-        -<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\\jenkins.war" --httpPort=8080\</arguments>
-        +\<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true -jar "%BASE%\\jenkins.war" --httpPort=8080\</arguments>
-```
+Set the `hudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode` Java system property to `true` to restore the old behavior.
+Refer to the ["Jenkins features controlled by system properties"](https://www.jenkins.io/doc/book/managing/system-properties/) for detailed instructions on Java system properties in Jenkins.
 
-# Report an issue
+## Report an issue
 
 Please report issues and enhancements through the [Jenkins issue tracker](https://www.jenkins.io/participate/report-issue/redirect/#15592).

src/main/resources/hudson/plugins/parameterizedtrigger/CounterBuildParameterFactory/help-validationFail.html

@@ -2,7 +2,7 @@
 This option determines the behaviour to take if the from,to and step values do not form a valid combination. One that gives a finite number of combinations.<br/>
 The actions that can be taken are:
   <ul>
-  <li><b>Fail the build step</b> This will fail the buildstep with a RuntimeException. (This is the default, and occured in older versions)</li>
+  <li><b>Fail the build step</b> This will fail the buildstep with a RuntimeException. (This is the default, and occurred in older versions)</li>
   <li><b>Don't trigger these projects</b> This will cause the projects not to be triggered at all for this configuration.</li>
   <li><b>Skip these parameters</b> This will allow the projects to be triggered without these parameters.</li>
   </ul>

src/main/resources/hudson/plugins/parameterizedtrigger/FileBuildParameterFactory/help-noFilesFoundAction.html

@@ -3,7 +3,7 @@
 The actions that can be taken are:
   <ul>
     <li><b>Don't trigger these projects</b> This will cause the projects not to be triggered at all for this configuration. </li>
-    <li><b>Skip these parameters</b> This will allow the projects to be triggered without these parameters. (This is the default, and occured in older versions)</li>
+    <li><b>Skip these parameters</b> This will allow the projects to be triggered without these parameters. (This is the default, and occurred in older versions)</li>
     <li><b>Fail the build step</b> This will fail the buildstep with a RuntimeException.</li>
   </ul>
 </div>

src/main/resources/hudson/plugins/parameterizedtrigger/SubversionRevisionBuildParameters/config.jelly

@@ -1,6 +1,6 @@
 <?jelly escape-by-default='true'?>
 <j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
-    <f:entry field="includeUpstreamParameters" title="${%Include/passthrough Upstream SVN Revisons}">
+    <f:entry field="includeUpstreamParameters" title="${%Include/passthrough Upstream SVN Revisions}">
         <f:checkbox default="false" />
     </f:entry>
 </j:jelly>