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

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.

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>