Closed tveon closed 1 year ago
/cc @quarkusio/devtools
You might try passing the javax.net.ssl.*
system properties via Maven surefire plugin <systemPropertyVariables>
?
Since QuarkusTests do a Maven resolution (directly using Aether, not via Maven CLI) of the augmentation classpath, I'd imagine surefire JVM settings are taken into account.
Nice, that actually "just worked". 👍
If anyone comes accros this later, then I add the following lines:
<javax.net.ssl.keyStoreType>${javax.net.ssl.keyStoreType}</javax.net.ssl.keyStoreType>
<javax.net.ssl.keyStore>${javax.net.ssl.keyStore}</javax.net.ssl.keyStore>
<javax.net.ssl.keyStorePassword>${javax.net.ssl.keyStorePassword}</javax.net.ssl.keyStorePassword>
Depending on your exact setup, you might also need to add a trustStore
...
Great to hear to you could solve this via configuration!
@aloubyansky WDYT, should we add a hint to the documentation or just close this right away?
It's worth to mention this in the docs. Not sure whether we can add support for it propagating these automatically.
Not sure whether we can add support for it propagating these automatically.
I don't think so, unless we create a mojo that runs before surefire and somehow "injects" certain properties into it. But I think only Maven extensions can do that.
${maven.home}
was added to the project generation etc. for the same reason.
That's kind of what I was thinking about. Perhaps it doesn't have to be even a mojo. Extensions are enabled for quarkus-maven-plugin.
I see one problem for multi-module projects in which you typically only have the quarkus-plugin in one (aggregating) module, but @QuarkusTest
classes can exist in every module. You'd need to add the quarkus-plugin there as well (or in a common parent).
Right. It should be documented first. Would you like to do that?
Is this still relevant?
Describe the bug Our internal Maven repository is using mTLS as part of the authentication, which requires a bit additional configuration of Maven. This configuration is, however, not picked up by the Quarkus bootstrapper, which then throws an exception when running test.
Expected behavior The
javax.net.ssl.*
properties fromMAVEN_OPTS
are successfully used to configure the HTTPS connection.Actual behavior I hope, this is "clear and concise". 🙂
Notice, that all dependencies to this point have been downloaded successfully, and it is also possible to run
mvn quarkus:dev
.To Reproduce
Steps to reproduce the behavior:
mvn test
Configuration N/A
Screenshots N/A - but see the stacktrace above.
Environment (please complete the following information):
uname -a
orver
:Darwin c02z707plvdv-c 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64
java -version
:mvnw --version
orgradlew --version
):Additional context 🤔