|   Based on the toolchain-configuration in the pom.xml Maven will search for
   |   matching <provides/> configuration. You can decide for yourself which key-value
   |   pairs to use. Often used keys are 'version', 'vendor' and 'arch'. By default
   |   the version has a special meaning. If you configured in the pom.xml '1.5'
   |   Maven will search for 1.5 and above.
   |
   | * configuration: Additional configuration for this tool.

        boolean active = ensureAtLeastOneNonNull(os);

        String actualOsName = context.getSystemProperties().get("os.name").toLowerCase(Locale.ENGLISH);
        String actualOsArch = context.getSystemProperties().get("os.arch").toLowerCase(Locale.ENGLISH);
        String actualOsVersion = context.getSystemProperties().get("os.version").toLowerCase(Locale.ENGLISH);

        if (active && os.getFamily() != null) {

  <name>Settings</name>
  <description>
    <![CDATA[
    <p>This is a reference for the user-specific configuration for Maven.</p>
    <p>Includes things that should not be distributed with the <code>pom.xml</code> file, such as developer identity, along with
    local settings, like proxy information.</p>
    <p>The default location for the settings file is {@code ~/.m2/settings.xml}.</p>
    ]]>
  </description>
  <defaults>
    <default>

   |
   | For example, if you have an integration testing plugin - like cactus - that needs to know where
   | your Tomcat instance is installed, you can provide a variable here such that the variable is
   | dereferenced during the build process to configure the cactus plugin.
   |
   | As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles

         * unique within a single POM. Upon multiple declarations, 2.x just kept the last one but retained the order of
         * the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */

     * creator of the problem, the general expectation is that the hint provides sufficient information to the user to
     * track the problem back to its origin. A concrete example for such a source hint can be the file path or URL from
     * which the settings were read.
     *
     * @return the hint about the source of the problem or an empty string if unknown, never {@code null}
     */
    @Nonnull

It's expected that `verification-metadata.xml` should only be updated with the commits that modify the build. There are some tips how
to perform such updates:

- Delete `components` section of `verification-metadata.xml` to avoid stockpiling of old unused dependencies. You may use the following command:
```bash
#macOS

        String jdkName = jenkinsEnv.jdkFromVersion(os, "${jdk}")
        String mvnName = jenkinsEnv.mvnFromVersion(os, "${runITsMvn}")
        echo "OS: ${os} JDK: ${jdk} => Label: ${osLabel} JDK: ${jdkName} Arch: s390x"

        String stageId = "${os}-jdk${jdk}-s390x"
        String stageLabel = "Run ITs ${os.capitalize()} Java ${jdk} on s390x"
        runITsTasks[stageId] = {
            node('s390x') {

     */
    public static final String OS_NAME = System.getProperty("os.name").toLowerCase(Locale.ENGLISH);

    /**
     * The OA architecture.
     */
    public static final String OS_ARCH = System.getProperty("os.arch").toLowerCase(Locale.ENGLISH);

    /**
     * The OS version.
     */
    public static final String OS_VERSION = System.getProperty("os.version").toLowerCase(Locale.ENGLISH);

    /**
     * OS Family
     */

 * enumerates only input dependencies. Another difference is that {@code JavaPathType} contains
 * some enumeration values used only at runtime and therefore not available in {@code javax.tool},
 * such as agent paths.
 *
 * @see org.apache.maven.api.services.DependencyResolverResult#getDispatchedPaths()
 *
 * @since 4.0.0
 */
@Experimental
public enum JavaPathType implements PathType {
    /**