apache/maven · error · ArtifactDeploymentException

Error retrieving previous build number for artifact '" + art

Error message

Error retrieving previous build number for artifact '" + artifact.getDependencyConflictId() + "': " + e.getMessage()

What it means

SnapshotTransformation.transformForDeployment prepares a -SNAPSHOT artifact for deployment and must compute the next build number by reading the repository's existing maven-metadata.xml (resolveLatestSnapshotBuildNumber). If that read throws RepositoryMetadataResolutionException, it is wrapped in ArtifactDeploymentException('Error retrieving previous build number for artifact <dependencyConflictId>: <cause>'), aborting the deploy before any file transfer.

Source

Thrown at compat/maven-compat/src/main/java/org/apache/maven/repository/legacy/resolver/transform/SnapshotTransformation.java:94

    }

    @Override
    public void transformForDeployment(
            Artifact artifact, ArtifactRepository remoteRepository, ArtifactRepository localRepository)
            throws ArtifactDeploymentException {
        if (artifact.isSnapshot()) {
            Snapshot snapshot = new Snapshot();

            // TODO Should this be changed for MNG-6754 too?
            snapshot.setTimestamp(getDeploymentTimestamp());

            // we update the build number anyway so that it doesn't get lost. It requires the timestamp to take effect
            try {
                int buildNumber = resolveLatestSnapshotBuildNumber(artifact, localRepository, remoteRepository);

                snapshot.setBuildNumber(buildNumber + 1);
            } catch (RepositoryMetadataResolutionException e) {
                throw new ArtifactDeploymentException(
                        "Error retrieving previous build number for artifact '" + artifact.getDependencyConflictId()
                                + "': " + e.getMessage(),
                        e);
            }

            RepositoryMetadata metadata = new SnapshotArtifactRepositoryMetadata(artifact, snapshot);

            artifact.setResolvedVersion(
                    constructVersion(metadata.getMetadata().getVersioning(), artifact.getBaseVersion()));

            artifact.addMetadata(metadata);
        }
    }

    public String getDeploymentTimestamp() {
        if (deploymentTimestamp == null) {
            deploymentTimestamp = getUtcDateFormatter().format(new Date());
        }

View on GitHub (pinned to e4093d4e12)

Solutions

Match the <snapshotRepository><id> in distributionManagement with a <server><id> entry (with username/password/token) in ~/.m2/settings.xml
Confirm the snapshot repository URL from the message's cause is reachable: curl it and expect either metadata XML or a clean 404, not 401/403/HTML
Fix proxy/mirror settings if a middleman intercepts the metadata request
Retry with mvn -U deploy after fixing access so stale local metadata does not mask the repair

Example fix

<!-- before: distributionManagement id has no matching server -->
<distributionManagement>
  <snapshotRepository>
    <id>snapshots</id>
    <url>https://repo.example.com/snapshots</url>
  </snapshotRepository>
</distributionManagement>

<!-- after: add matching credentials in settings.xml -->
<servers>
  <server>
    <id>snapshots</id>
    <username>ci-user</username>
    <password>${env.REPO_TOKEN}</password>
  </server>
</servers>

Defensive patterns

Strategy: try-catch

Validate before calling

// Before mvn deploy, verify credentials exist for each distributionManagement repo id
Settings settings = settingsBuilder.buildSettings();
for (String serverId : List.of(distMgmtSnapshotRepoId, distMgmtReleaseRepoId)) {
    Server server = settings.getServer(serverId);
    if (server == null || isBlank(server.getUsername())) {
        throw new IllegalStateException("No credentials configured in settings.xml for server id '" + serverId + "'");
    }
}

Try / catch

try {
    deployer.deploy(...);
} catch (ArtifactDeploymentException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Error retrieving previous build number")) {
        Throwable cause = e.getCause(); // RepositoryMetadataResolutionException with HTTP details
        failBuildWithHint("Cannot read snapshot metadata from the deploy repository — check server id '"
            + repo.getId() + "', credentials and URL", cause);
    } else {
        throw e;
    }
}

Prevention

Keep <server><id> entries in settings.xml in exact lockstep with distributionManagement repository ids — assert this in a pre-deploy CI step
Dry-run reachability: curl the snapshot repository metadata URL with the same credentials before deploying
Prefer dedicated CI users with deploy-only permissions to avoid 403 surprises from shared accounts

When it happens

Trigger: mvn deploy of a SNAPSHOT where the target repository's metadata cannot be fetched: 401/403 because no <server> credentials match the repository id in distributionManagement, repository URL wrong or unreachable, proxy blocking the request, or the repository returning an error page for the metadata path.

Common situations: Missing or mislabeled server id in settings.xml versus <distributionManagement><snapshotRepository><id>; CI deploying behind a corporate proxy; typo in the snapshot repository URL; first deploy to a newly created repository whose permissions are wrong.

Related errors

AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21). Data as JSON: /api/errors/63a90927f43c300d. Report an issue: GitHub.