</configuration>
			</plugin>
			<plugin>
				<artifactId>maven-antrun-plugin</artifactId>
				<dependencies>
					<dependency>
						<groupId>org.apache.ant</groupId>
						<artifactId>ant</artifactId>
						<version>1.10.11</version>
					</dependency>
				</dependencies>
				<configuration>
					<target>
						<ant antfile="${basedir}/dbflute.xml" target="download.dbflute" />

            List<org.apache.maven.api.model.Dependency> dependencies = importMgmt.getDependencies().stream()
                    .filter(candidate -> exclusions.stream().noneMatch(exclusion -> match(exclusion, candidate)))
                    .map(candidate -> addExclusions(candidate, exclusions))
                    .collect(Collectors.toList());
            importMgmt = importMgmt.withDependencies(dependencies);
        }

            <type>DependencyManagement</type>
          </association>
        </field>
        <field>
          <name>dependencies</name>
          <version>3.0.0+</version>
          <description>
            This element describes all the dependencies associated with a project.
            These dependencies are used to construct a classpath for your
            project during the build process. They are automatically downloaded from the

        // file reference. But this may be a Maven Plugin that we need to resolve from a remote repository
        // as well as its dependencies.

        if (request.isResolveRoot() /* && rootArtifact.getFile() == null */) {
            try {
                resolve(rootArtifact, request.getRemoteRepositories(), session);

# installed into a virtual environment, and then that venv is used to run all
# bazel tests with a special flag "--define=no_tensorflow_py_deps=true", which
# drops all the bazel dependencies for each py_test; this makes all the tests
# use the wheel's TensorFlow installation instead of the one made available
# through bazel. This must be done in a different root directory, //bazel_pip/...,

        // For some reason with the introduction of MNG-1577 we have the case in Yoko where a depMan section has
        // something like the following:
        //
        // <dependencyManagement>
        //     <dependencies>
        //         <!--  Yoko modules -->
        //         <dependency>
        //             <groupId>org.apache.yoko</groupId>
        //             <artifactId>yoko-core</artifactId>

# See the License for the specific language governing permissions and
# limitations under the License.

# Init script downloads or updates envoy and the go dependencies. Called from Makefile, which sets
# the needed environment variables.

set -o errexit
set -o nounset
set -o pipefail

if [[ "${TARGET_OUT_LINUX:-}" == "" ]]; then

    - [API Change](#api-change)
    - [Feature](#feature)
    - [Documentation](#documentation)
    - [Bug or Regression](#bug-or-regression)
    - [Other (Cleanup or Flake)](#other-cleanup-or-flake)
  - [Dependencies](#dependencies)
    - [Added](#added)
    - [Changed](#changed)
    - [Removed](#removed)
- [v1.32.0-alpha.2](#v1320-alpha2)
  - [Downloads for v1.32.0-alpha.2](#downloads-for-v1320-alpha2)
    - [Source Code](#source-code-1)

import java.util.Optional;

import org.apache.maven.api.annotations.Experimental;
import org.apache.maven.api.annotations.Nonnull;

/**
 * The option of a command-line tool where to place the paths to some dependencies.
 * A {@code PathType} can identify the Java class-path, the Java module-path,
 * or another kind of path for another programming language for example.
 * Path types are often exclusive. For example, a dependency should not be

    "path": "platforms/core-runtime/distributions-core",
    "unitTests": false,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "distributions-dependencies",
    "path": "subprojects/distributions-dependencies",
    "unitTests": false,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "distributions-full",
    "path": "subprojects/distributions-full",