mvn --settings: Use a Custom settings.xml
mvn -s (--settings) tells Maven to read a specific settings.xml, the standard way to supply private-repo credentials and mirrors in CI.
CI should not depend on a developer ~/.m2/settings.xml. -s points at a checked-in or generated settings file so repo auth and mirrors are explicit.
What it does
-s / --settings overrides the user settings file (default ~/.m2/settings.xml). It holds <servers> (credentials matched by repository/server id), <mirrors>, and <profiles>. -gs / --global-settings overrides the global file. This is how a build authenticates to Nexus/Artifactory.
Common usage
mvn -B -s ci-settings.xml deploy
mvn -B --settings $CI_SETTINGS install
# credentials usually come from env via property interpolation
mvn -B -s ci-settings.xml -Drepo.user=$U -Drepo.pass=$P deployFlags
| Flag | What it does |
|---|---|
| -s / --settings <file> | Use this user settings.xml |
| -gs / --global-settings <file> | Use this global settings.xml |
| -Dkey=value | Inject secrets via property interpolation |
| -B | Batch mode for CI |
In CI
Generate or commit a settings.xml whose <server> ids match your repository ids, and pass it with -s. Keep secrets out of the file by interpolating env vars (e.g. ${env.REPO_TOKEN}). Cache ~/.m2/repository, but never cache or commit raw credentials.
Common errors in CI
"Could not read settings.xml" or "Error reading settings file" means a bad path or malformed XML. A 401 on deploy despite a settings file means the <server> id does not match the repository/distributionManagement id. "Some problems were encountered while building the effective settings" lists the exact element at fault.