Quarkus: Maven artifact cannot be downloaded while bootstrapping app

[knutwannheden]

Describe the bug
When running an @QaurkusTest annotated test the Maven resolver configured by Quarkus fails to download an artifact from our Maven repository. The remote Maven repository is hosted by GitLab and requires a security token to be provided as an HTTP header. This has been configured in Maven's settings.xml, but it isn't picked up by Quarkus.

Expected behavior
Quarkus should be able to download the Maven artifact just like the Maven build does it.

Actual behavior
When running the test using Maven the test fails if the deployment artifact of a custom Quarkus extension isn't already present in the local Maven repository, because it can't download it from the remote repository. When running the test the following error gets logged:

java.lang.RuntimeException: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for ch.mobi.mcs:mcs-b2esimple-service::jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for ch.mobi.mcs:mcs-b2esimple-service::jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.resolver.AppModelResolverException: Failed to inject extension deployment dependencies for ch.mobi.mcs:mcs-b2esimple-service:jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.BootstrapDependencyProcessingException: No dependencies collected for Quarkus extension deployment artifact ch.mobi.gluon:gluon-commands-deployment:jar:0.1.424 while at least the corresponding runtime artifact ch.mobi.gluon:gluon-commands:jar:0.1.424 is expected

I suspect the problem is in BootstrapMavenContext. In newRepositorySystemSession() the code adds XmlPlexusConfiguration config properties for the Maven repository servers as configured in settings.xml, but the corresponding WagonConfigurator service implementation PlexusWagonConfigurator is not registered in newRepositorySystem(). Registering that service implementation might fix the issue, but I have not had time to verify that yet.

To Reproduce
Not so easy... I can fill this out at a later stage, if still required.

Configuration
In ~/.m2/settings.xml the additional HTTP header is configured like this:

    <servers>
        <server>
            <id>gitlab-maven</id>
            <configuration>
                <httpHeaders>
                    <property>
                        <name>Private-Token</name>
                        <value>XXXXXXXXXXXXXXXXXX</value>
                    </property>
                </httpHeaders>
            </configuration>
        </server>
    </servers>

Screenshots

Environment (please complete the following information):

• Output of uname -a or ver: MINGW64_NT-10.0-19624
• Output of java -version: openjdk version "11.0.6" 2020-01-14 LTS
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.4.2.Final
• Build tool (ie. output of mvnw --version or gradlew --version): Maven 3.6.3

Additional context

[quarkusbot]

/cc @quarkusio/devtools

[aloubyansky]

@knutwannheden thanks for reporting the issue. It sounds like #9255, doesn't it?

[knutwannheden]

Yes, it does. Quite the coincidence getting these both issues now. Or is it a regression in 1.4?

Also, what do you think of my analysis? Possibly easier to verify with the use case of the other issue.

[aloubyansky]

I'll have to verify that. Thanks. We also started a discussion with @stephenc on zulip here https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Issue.209255, in case you want to follow.

[stephenc]

Yeah I think the analysis seems plausible. are you using <mirrorOf>*</morrorOf> or is this repository just an additional one?

[knutwannheden]

No mirror, just an additional repo.

[stephenc]

Well I don’t envy @aloubyansky so 🤣

[aloubyansky]

I have to say, besides the actual bugs you hit, i'm intrigued by your custom Quarkus extensions. That's definitely great to hear. If you could share a bit of info about what they are about, that'd be really great. Another thing about it, we are still shaping up the build step/item apis, so knowing how it's used could actually help us keep it more stable.

[aloubyansky]

@stephenc in this specific case, you guys actually help a lot providing details and analysis. So, I'm staying positive :)

[aloubyansky]

but the corresponding WagonConfigurator service implementation PlexusWagonConfigurator is not registered in newRepositorySystem().

That does not appear to be enough.

[knutwannheden]

No, unfortunately. The implementation class only works inside the Plexus DI container. Looks like Quarkus will have to roll its own. For many (all?) settings there appear to be corresponding Eclipse Aether properties which can be set. Maybe that is the way to go?

[aloubyansky]

yes, i have it working actually.