[alexandreferris]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Update JVM SDK version to 0.3.1 using new Wire Maven repository

[claude]

Review: Update JVM SDK to 0.3.1

Small, focused change. The version bump and the extra repository both make sense. One suggestion is worth taking before merge.

🔒 Limit the new repository to Wire artifacts (recommended)

As written, maven.wire.com is a general-purpose repository. Gradle checks repositories in the order they are declared, so this has two effects:

• If an artifact isn't on Maven Central (for example a typo'd or yanked transitive dependency), Gradle asks maven.wire.com for it. You don't want third-party coordinates resolving from a second source.
• com.wire:* artifacts are looked up on Maven Central first. Anything published there under that coordinate takes precedence over the Wire repo. This is the classic dependency-confusion setup.

exclusiveContent fixes both problems: com.wire artifacts come only from the Wire repo, and nothing else is ever requested from it.

repositories {
    mavenCentral()
    exclusiveContent {
        forRepository {
            maven {
                name = "Wire"
                url = uri("https://maven.wire.com/")
            }
        }
        filter {
            includeGroup("com.wire")
        }
    }
}

(If the SDK pulls in other Wire-hosted groups, such as com.wire.* subgroups, use includeGroupByRegex("com\\.wire(\\..*)?").)

This also saves a few HTTP round-trips during resolution, because Gradle stops probing two repositories for every dependency.

⚙️ Build / CI considerations

• The Dockerfile build stage runs ./gradlew shadowJar and now needs network access to maven.wire.com. Please make sure the staging/CI build environments (and any egress allowlists) can reach it.
• Consider enabling Gradle dependency verification (gradle/verification-metadata.xml) at some point. It matters more now that artifacts come from a non-Central repository. Not a blocker for this PR.

📝 Minor

• Since it's a patch bump (0.3.0 → 0.3.1), I don't expect any API changes. A line in the PR description on what 0.3.1 fixes or changes would still help reviewers and the changelog.
• Unrelated, but I noticed it nearby: implementation(libs.ktor.server.core) is declared twice in build.gradle.kts (lines 39 and 41). It's harmless and could be removed in a follow-up.

🧪 Tests

No code changes, so no new tests are needed. A green CI build (pull-request.yml) is enough to confirm that the artifact resolves from the new repository.

Overall LGTM once the repository is scoped with exclusiveContent 👍