skip to content

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?

level: juniorimportance: must knowfreq 70%

answer

  1. credentials(PasswordCredentials::class)
  2. <repoName>Username / <repoName>Password
  3. ~/.gradle/gradle.properties
  4. ORG_GRADLE_PROJECT_ env prefix
  5. lazy — only needed at publish

basics

~10 s

Inside 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 s

In 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 lines
kotlin
publishing {
    repositories {
        maven {
            name = "myRepo"
            url = uri("https://repo.example.com/releases")
            credentials(PasswordCredentials::class)
        }
    }
}

// In ~/.gradle/gradle.properties:
// myRepoUsername=alice
// myRepoPassword=s3cret

go deeper

for a junior

Know that you call credentials(PasswordCredentials::class) and that values come from gradle.properties; recall the <repoName>Username/<repoName>Password pattern.

for a middle

Explain the property naming convention precisely and name ~/.gradle/gradle.properties plus the ORG_GRADLE_PROJECT_ env prefix as alternative sources.

for a senior

Discuss lazy evaluation (only needed when publish is in the graph) and precedence ordering of property sources.

for a principal

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.

context

resolving links…