Raising JDK requirements

[tesshucom]

We have already announced that JDK 11 is the minimum requirement. The current Maven profile does not default to 11, so we'll change it.

• Change profiler configuration
• Check if the autobuilder of LGTM can run with JDK11. The autobuilder of CodeQL has been confirmed to work properly.
• Delete unnecessary profiles. Assuming JDK11 or later, no version branching profile is required.
• Change profiles.
• [The site's web page] Change compilation procedure (v110.0.0 RELEASE #922)

This allows for officially incompatible code changes. Related #838.

---

Profiles

In theory, it's one...

<maven.compiler.release>11</maven.compiler.release>

-> It overrides the version referenced by Spring, so it is as follows.

<java.version>11</java.version>
<maven.compiler.release>${java.version}</maven.compiler.release>

A profile to specify the version was created to cover up the specification method that differs depending on the version of Maven&JDK. We can remove this now, but that may be too hurry. If the purpose is clear, it may be better to keep the current method.

• We can specify it with -Djava.version option dynamically, but cannot define a available input range with pom. Verification of JDK 11 and later versions is very fast and the results will be replaced in a few months. The profile is verbose, but it can define at the time the active version that is available as a result of validation. POM too simple, it will be confusing.
• Some of the source generation tools have similar references, as SpringBoot. There is no guarantee that simple pom description will be maintained in the future. By specifying the version from the outside via the profile, even if the internal version control becomes complicated, it can be absorbed (as it was done in JDK8-11).

[tesshucom]

[tesshucom]

Change default value of package to Jetty & JDK11. When compiling manually, tomcat will not be selectable unless you specify options.