英文:

maven-plugin-testing-harness encounters No connector factories available during test execution

问题 {#heading}

使用maven-plugin-testing-harness时，在测试执行过程中遇到了以下错误。似乎测试无法在加载pom.xml文件作为测试的一部分时解析来自Maven仓库的构件。仓库的URL是有效的，且构件存在于仓库中。

我们不能简单地将依赖项添加到我们项目的pom.xml文件中，因为测试正在寻找一个与我们当前版本冲突的旧版本。我们在测试pom文件中配置的插件也遇到了这个问题，这些插件使用了我们项目pom中已经存在的依赖项的不同版本。

[ERROR] Non-resolvable import POM: Could not transfer artifact <REDACTED GROUP ID>:<REDACTED ARTIFACT ID>:pom:1.1.2 from/to repository (https://REDACTED VALID URL/): No connector factories available @ line 44, column 19
        at org.apache.maven.model.building.DefaultModelProblemCollector.newModelBuildingException(DefaultModelProblemCollector.java:197)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:568)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:454)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:267)
        at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:173)
        ... 47 more

然后，由于这个错误，Maven无法加载Maven Project类，测试失败。

网上的建议表明连接器库在Maven测试类路径中不可用。这似乎是有道理的，但添加它们并没有影响到情况。 英文:

When using the maven-plugin-testing-harness, the following error is encountered during test execution. It appears that the test cannot resolve artifacts from the Maven repository while loading a pom.xml file as part of the test. The url for the repository is valid and the artifact exists in the repository.

We cannot simply add the dependency to our project's pom.xml file because the test is looking for an older version that would conflict with our current version. We have also run into this with plugins configured in our test pom files that use a different version of a dependency we already have in our project pom.

<code>[ERROR] Non-resolvable import POM: Could not transfer artifact <REDACTED GROUP ID>:<REDACTED ARTIFACT ID>:pom:1.1.2 from/to repository (https://REDACTED VALID URL/): No connector factories available @ line 44,
column 19
at org.apache.maven.model.building.DefaultModelProblemCollector.newModelBuildingException(DefaultModelProblemCollector.java:197)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:568)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:454)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:267)
at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:173)
... 47 more</code>

The test then fails as Maven cannot load the Maven Project class due to this error.

Guidance online suggests that the connector libraries are not available in the Maven test classpath. This seemed plausible, but adding them in did not impact the situation.

答案1 {#1}

得分: 0

以下是翻译好的部分：

这个解决方案更像是一种权宜之计，但让我们能够继续前进。

我们在项目中添加了一个新的模块（例如，test-primer），并将其分层到我们的挑战模块之前构建。然后，我们在该模块中添加了依赖项，这会触发将所需的Maven构件下载到我们的本地存储库，以便在运行测试时可用。这种间接方式允许我们绕过了一开始阻止我们直接添加到测试模块中的版本冲突。

以下是一个示例（GitHub上提供了实际更改集）：

在父POM中添加新模块test-primer：

    <modules>
        <module>test-primer</module>
        <module>fermenter-mda</module>
    </modules>

test-primer的POM文件触发所需依赖项的下载：

<project>
    ...
    <artifactId>test-primer</artifactId>
    <name>Fermenter::Test Primer</name>
    <description>一个临时模块，用于解决fermenter-maven-plugin中的测试依赖问题</description>
&lt;!--
    注意：目前，Maven测试工具需要访问特定版本的commons-io等其他依赖项，
    但我们在fermenter-mda中使用了更新的版本。因此，这是一种不太美观的解决方法，
    确保版本可用于本地环境的.m2/repository，以便在运行测试时能够解析它。
    由于我们正在模拟Maven插件进行测试，我们不能通过正常方式忽略或手动设置这些依赖项。
--&gt;

&lt;build&gt;
    &lt;plugins&gt;
        &lt;plugin&gt;
            &lt;groupId&gt;org.technologybrewery.habushu&lt;/groupId&gt;
            &lt;artifactId&gt;habushu-maven-plugin&lt;/artifactId&gt;
            &lt;version&gt;2.4.1&lt;/version&gt;
            &lt;extensions&gt;true&lt;/extensions&gt;
        &lt;/plugin&gt;
    &lt;/plugins&gt;
&lt;/build&gt;

</project>

英文:

The solution below is more of a workaround, but enables us to move forward.

We added a new module (e.g., test-primer) to our project and layered it into the build prior to our challenged module. We then added the dependencies to that module, which triggers the download to our local repository so that the needed Maven artifacts are available when our test runs. This layer of indirection allows us to get around the version conflicts that prevented us from simply adding the to our test module in the first place.

An example is below (actual change set is available on GitHub):

New module test-primer added to parent pom:

    <modules>
        <module>test-primer</module>
        <module>fermenter-mda</module>
    </modules>

test-primer pom triggers download of needed dependencies:

<project>
    ...
    <artifactId>test-primer</artifactId>
    <name>Fermenter::Test Primer</name>
    <description>A temp module to work around test dependency issues in fermenter-maven-plugin</description>
<!--
    NB: Currently, the maven test harness needs access to a specific version of commons-io, among other dependencies,
    but we leverage newer versions in fermenter-mda.  As such, this is an ugly workaround that ensures that the
    version is available in the .m2/repository of the local environment so that when the test runs, it
    can be resolved.  Because we are mocking the Maven plugin for testing, we cannot ignore or manually set
    these dependencies via normal means.
 -->

<build>
    <plugins>
        <plugin>
            <groupId>org.technologybrewery.habushu</groupId>
            <artifactId>habushu-maven-plugin</artifactId>
            <version>2.4.1</version>
            <extensions>true</extensions>
        </plugin>
    </plugins>
</build>

</project>