How do you supply a username and password to a Maven repository in a Gradle publishing block, and where does Gradle get those values from?
answer
- credentials(PasswordCredentials::class)
- <repoName>Username / <repoName>Password
- ~/.gradle/gradle.properties
- ORG_GRADLE_PROJECT_ env prefix
- lazy — only needed at publish
basics
~10 sInside the repository, call credentials(PasswordCredentials::class). Gradle then reads <repoName>Username and <repoName>Password from gradle.properties or environment variables, where <repoName> is the repository's name.
solid answer
~30 sIn a `maven { ... }` repository you call `credentials(PasswordCredentials::class)` (Kotlin) instead of hardcoding values. Gradle automatically looks for two properties named after the repository: `<repoName>Username` and `<repoName>Password`. So a repository named `myRepo` resolves `myRepoUsername` and `myRepoPassword`. These can come from `~/.gradle/gradle.properties` (so they stay off the project and out of version control) or from environment variables `ORG_GRADLE_PROJECT_myRepoUsername` / `ORG_GRADLE_PROJECT_myRepoPassword`. This keeps secrets out of the build script. The credentials are evaluated lazily, so they're only required when a task that actually needs them (like `publish`) runs.
code
kotlin · 13 linespublishing {
repositories {
maven {
name = "myRepo"
url = uri("https://repo.example.com/releases")
credentials(PasswordCredentials::class)
}
}
}
// In ~/.gradle/gradle.properties:
// myRepoUsername=alice
// myRepoPassword=s3cretgo deeper
Know that you call credentials(PasswordCredentials::class) and that values come from gradle.properties; recall the <repoName>Username/<repoName>Password pattern.
Explain the property naming convention precisely and name ~/.gradle/gradle.properties plus the ORG_GRADLE_PROJECT_ env prefix as alternative sources.
Discuss lazy evaluation (only needed when publish is in the graph) and precedence ordering of property sources.
Tie into org-wide secret management — injecting via CI env vars, never committing, standardizing repo names so conventions hold across many projects.
## The problem A `maven` repository for publishing usually needs authentication. You could write `username = "alice"` / `password = "s3cret"` directly, but that leaks secrets into the build script and version control. Gradle provides a convention-based mechanism to avoid this. ## `credentials(PasswordCredentials::class)` Inside a repository declaration you call: ```kotlin maven { name = "myRepo" url = uri("https://repo.example.com/releases") credentials(PasswordCredentials::class) } ``` When you pass the **type** `PasswordCredentials::class` (rather than a configuration lambda), Gradle resolves the username and password from **Gradle properties** using a naming convention derived from the repository's `name`: - `<repoName>Username` - `<repoName>Password` So for a repo named `myRepo`, Gradle looks up `myRepoUsername` and `myRepoPassword`. ## Where the values come from Gradle properties can be supplied from several sources (highest precedence wins): 1. `-PmyRepoUsername=...` on the command line 2. Environment variable `ORG_GRADLE_PROJECT_myRepoUsername` 3. System property `-Dorg.gradle.project.myRepoUsername` 4. `gradle.properties` in `~/.gradle/` (per-user, the recommended place for secrets) 5. `gradle.properties` in the project root Putting secrets in `~/.gradle/gradle.properties` keeps them off the repo entirely. ## Lazy evaluation Credentials resolved this way are **lazy**: Gradle only requires them when a task that consumes the repository (e.g. `publish`) is part of the task graph. So you can run `./gradlew build` without setting them; you only need them for `./gradlew publish`. If they're missing at that point, Gradle fails fast with a clear message naming the missing property. ## Inline form (less preferred) You can also pass a lambda to set values explicitly, which is useful when reading from a custom property name: ```kotlin credentials { username = providers.gradleProperty("customUser").get() password = providers.gradleProperty("customPass").get() } ``` But the type-based form is preferred because it follows the convention and integrates with lazy resolution.
- If the repository is named `myRepo`, what two property names does Gradle look up?`myRepoUsername` and `myRepoPassword` — the repository name is prefixed onto `Username`/`Password`.
- Why is `~/.gradle/gradle.properties` preferred over the project's `gradle.properties` for these values?It's per-user and outside the project directory, so secrets never get committed to version control.
saying these in an interview costs you the question
- Hardcoding `username`/`password` literals directly in the build script.
- Claiming the property names are fixed (like just `username`) rather than derived from the repository name.
- Committing the project `gradle.properties` containing the password.