Is there any way to use the current settings.xml used by main Maven process ?

[fmarot]

In my CI, the settings.xml file is located 'somewhere' that I know only at runtime in an env variable. So all my Maven builds are run with this parameter:

-settings ${MAVEN_SETTINGS_XML}

The tests using @maventest seem to inherit the default settings.xml of Maven because they can seem to find dependencies located in my company's private repository.

1- I would have expected the tests to inherit by default from the main Maven process' settings.xml. It does not seem to be the case.
2- is there a workaround ? I tried the following but it does not work:

@MavenOption(value = "--settings", parameter = "${MAVEN_SETTINGS_XML}")

[khmarbaise]

A user settings is by default located in the home directory of the user.. on CI systems it is usually provided incl. credentials etc... At the moment there is no support for environment variables in the paremeter ...

[fmarot]

And no possibility to reuse the settings.xml used by the 'main' Maven process ?

I do not think I have such a specific requirement: a good practise in Jenkins is not to rely on anything already installed on the worker node but to define exactly what the build requires. Hence I define my build requires a vanilla Maven 3 installation as well as a setting.xml I pre-defined in the Jenkins master but the maven-it-extension does not 'see' this specific settings.xml.

For my use case this is not important because I can test my own plugin with only dependencies from Maven Central, but I think this could cause problem if builds require a specific repository.

[khmarbaise]

The usage can be done via @MavenOption as you already mentioned, but as I wrote the limitation is at the moment that the parameter does not support environment variables.

If nothing is defined the execution uses the default provided settings.xml by Maven itself... (which can be looked up during the Maven execution by using -X to see the information)..

In Jenkins you usually provide the settings.xml via the Config File Provider plugin and enrich it with credentials from the credentials store(that means each build get provided a settings.xml not stored on a worker node or alike) ... also including references to repository managers to consume dependencies from it... in a corporate environment..