下面的解决方案更像是一种变通方法，但它使我们能够向前迈进。
我们在项目中添加了一个新模块（例如，test-primer），并将其分层到我们挑战模块之前的构建中。然后，我们将依赖项添加到该模块，这将触发下载到本地存储库，以便在测试运行时可以使用所需的Maven工件。这个间接层允许我们绕过版本冲突，这些冲突使我们无法在一开始就简单地将添加到测试模块中。
下面是一个示例（实际更改集可在GitHub上获得）：
新模块test-primer添加到父pom：

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

test-primer pom触发下载所需依赖项：

<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>