docs: Upgrade HTTP urls to HTTPS in documentation

README.md

@@ -84,7 +84,7 @@ Additional Resources
 + #Maven IRC channel on freenode.org
 
 [license]: https://www.apache.org/licenses/LICENSE-2.0
-[ml-list]: http://maven.apache.org/mailing-lists.html
+[ml-list]: https://maven.apache.org/mailing-lists.html
 [code-style]: https://maven.apache.org/developers/conventions/code.html
 [cla]: https://www.apache.org/licenses/#clas
 [maven-wiki]: https://cwiki.apache.org/confluence/display/MAVEN/Index

src/site/markdown/examples/compile-using-different-jdk.md

@@ -28,8 +28,8 @@ Each of those plugins need a tool of the JDK to operate: `javac`, `javadoc`, `ja
 A toolchain is a way to specify the path to the JDK to use for all of those plugins in a centralized manner,
 independent from the one running Maven itself.
 
-To set this up, refer to the [Guide to Using Toolchains](http://maven.apache.org/guides/mini/guide-using-toolchains.html),
-which makes use of the [Maven Toolchains Plugin](http://maven.apache.org/plugins/maven-toolchains-plugin/).
+To set this up, refer to the [Guide to Using Toolchains](https://maven.apache.org/guides/mini/guide-using-toolchains.html),
+which makes use of the [Maven Toolchains Plugin](https://maven.apache.org/plugins/maven-toolchains-plugin/).
 
 With the maven-toolchains-plugin you configure 1 default JDK toolchain for all related maven-plugins.
 Since maven-compiler-plugin 3.6.0 when using with Maven 3.3.1+ it is also possible to give the plugin its own toolchain,
@@ -69,7 +69,7 @@ as discussed in the next paragraph.
 ```
 
 The above example uses a `JAVA_11_HOME` property in order to avoid hard-coding a filesystem path for the executable.
-Each developer defines this property in [settings.xml](http://maven.apache.org/ref/current/maven-settings/settings.html),
+Each developer defines this property in [settings.xml](https://maven.apache.org/ref/current/maven-settings/settings.html),
 or sets an environment variable, so that the build remains portable.
 
 ```xml
@@ -92,4 +92,4 @@ or sets an environment variable, so that the build remains portable.
 ```
 
 If you build with a different JDK, you may want to
-[customize the jar file manifest](http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html).
+[customize the jar file manifest](https://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html).

src/site/markdown/examples/set-compiler-source-and-target.md

@@ -69,7 +69,7 @@ or configure the plugin directly:
 **Note:** Merely setting the `target` option does not guarantee that your code actually runs on a JDK with the specified version.
 The pitfall is unintended usage of APIs that only exist in later JDKs which would make your code fail at runtime with a linkage error.
 To avoid this issue, you can either configure the compiler's boot classpath to match the target JDK,
-or use the [Animal Sniffer Maven Plugin](http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/)
+or use the [Animal Sniffer Maven Plugin](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/)
 to verify your code doesn't use unintended APIs,
 or better yet use the [release](./set-compiler-release.html) option.
 

src/site/markdown/index.md

@@ -50,7 +50,7 @@ Especially for fixing bugs it is crucial that the developers can reproduce your
 For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated.
 Of course, patches are welcome, too.
 Contributors can check out the project from our [source repository](./scm.html) and will find supplementary information
-in the [guide to helping with Maven](http://maven.apache.org/guides/development/guide-helping.html).
+in the [guide to helping with Maven](https://maven.apache.org/guides/development/guide-helping.html).
 
 The following pages describes how to use the plugin beyond the default
 "one source directory, one module, one release" default configuration:

src/site/markdown/multirelease.md

@@ -19,7 +19,7 @@ under the License.
 
 # Multi Release
 
-With [JEP-238](http://openjdk.java.net/jeps/238) the support of multirelease JARs was introduced.
+With [JEP-238](https://openjdk.org/jeps/238) the support of multirelease JARs was introduced.
 This means that you can have Java version dependent classes inside one JAR.
 Based on the runtime, it will pick up the best matching version of a class.
 The output files of a multi-release project are organized like below: