Problems Uploading/Updateing maven-metadata.xml

[M-Marvin]

Select Topic Area

Question

Body

I am currently working on an custom build tool which also manages maven dependencies and repositories.
I recently got it working with some local maven repository servers to test it on (uploading and downloading artifacts).

But I have problems getting it working with GitHub Packages, uploading my artifacts works fine, but if I try to update the maven-metadata.xml using an HTTPS PUT request, I get the HTTP status code 409 Conflict.
My first guess was that this is because the file already exists, so I tried to send an HTTP DELETE request first, but this request was responded to with 405 Method not allowed.

Are there some special conditions that I must met before I can update an file ?
The initial upload of the first maven-metadata.xml works fine, like all the other artifacts, just updating it seems to give me errors.

Out of curiosity, I tried to spy on gradle during an upload using Wireshark, and from what I can tell it does the same as I do.
It first downloads the current metadata using GET, then uploads the new one using PUT.
I have no Idea why my requests get denied, and why only the ones for updating an existing file.

[0h-yea]

Hey! I recently ran into the same issue while building a custom tool to manage Maven artifacts. I had no trouble uploading JARs and even the initial maven-metadata.xml. But every time I tried to update the metadata using an HTTPS PUT, I got a 409 Conflict. I also tried deleting it with a DELETE request — only to get a 405 Method Not Allowed.

After a bunch of digging (and Wireshark-ing some Gradle traffic for good measure), here’s what I found:

---

🚫 GitHub Packages Maven Registry is Immutable

The Maven registry in GitHub Packages does not allow overwriting existing files, including maven-metadata.xml. This includes:

• ❌ No overwriting artifacts (like JARs or metadata)
• ❌ No deleting individual files with DELETE
• ✅ Only first-time uploads to a path (like a specific version folder) are allowed

This is by design — GitHub enforces immutable package versions to ensure consistency and reproducibility.

---

✅ What Tools Like Maven/Gradle Actually Do

You might see tools like Gradle doing PUT on maven-metadata.xml, but they don't update existing files on GitHub Packages. Here's how they avoid the issue:

• They only write metadata once per version
• They publish each version to a new path (like /1.0.1/)
• The metadata is either generated locally or by the tool, but never updated remotely

So even if a PUT is in the trace, it's for a new path, not an overwrite.

---

🛠️ Solution / What You Should Do

✅ Recommended (Safe) Approach:

1. Avoid manual PUT or DELETE on maven-metadata.xml.

2. Always publish to new versioned paths, e.g.:

   com/example/my-artifact/1.2.3/
   

3. Let tools like mvn deploy or gradle publish handle metadata creation.

💡 If You Need Full Control:

If you’re building a custom tool and need more flexibility (like metadata updates or artifact deletion), consider using a full Maven-compatible repository manager like:

• [🔷 Nexus Repository OSS](https://www.sonatype.com/products/repository-oss)
• [🟢 JFrog Artifactory](https://jfrog.com/artifactory/)
• [🟥 Apache Archiva](https://archiva.apache.org/)

These give you full control over:

• Metadata updates
• Snapshot/version policies
• HTTP-based API interactions

---

💬 TL;DR

GitHub Packages for Maven is version-immutable — once you upload maven-metadata.xml or an artifact, you can't update or delete it. You’ll always get 409 or 405 errors if you try.

If you need to update metadata or overwrite files, use a proper Maven repository manager like Nexus or Artifactory.

Hope that clears it up! 🔧💡

---

Let me know if you want a curl example or code snippet to work around this for publishing!

[Shobhit21Mishra]

Hi — great question, and I appreciate the detailed explanation of what you’ve tried so far.

GitHub Packages' Maven registry does have a couple of limitations and behaviors that differ from a typical Maven repository manager like Nexus or Artifactory:

📌 Key points to note:
GitHub Packages Maven API does not support overwriting existing artifacts or metadata files once published.
This is by design — once a package version is published, it's considered immutable to ensure consistency and traceability.

This is why your PUT request to update maven-metadata.xml returns a 409 Conflict — because a file with the same path already exists and the registry doesn’t allow overwriting it.

The DELETE method isn’t supported on individual files either — hence your 405 Method Not Allowed response. GitHub only allows deleting an entire package version via their REST API for Packages, not individual files within a package.

📌 How does Gradle or Maven manage this?
When tools like Gradle or Maven upload artifacts, they generally:

Upload the maven-metadata.xml only if it doesn't already exist, or

Work with a repository that allows metadata merging on the server side (like Nexus/Artifactory do — which GitHub Packages currently doesn't support).

On GitHub Packages, this limitation makes it hard to implement snapshot-like behavior where metadata is frequently updated.

📌 Possible Workarounds:
Use unique version numbers (e.g., timestamped or incremented versions) for each artifact upload to avoid conflicts.

Structure your build tool to avoid updating existing maven-metadata.xml on GitHub Packages.

If necessary, delete the entire package version via the GitHub Packages REST API and re-upload.

📌 Suggestion:
You might consider logging a feature request with GitHub Support or checking their community discussions to see if others have workarounds or if metadata merging is on their roadmap.

[M-Marvin]

Here is what I captured from an Gradle publish task when uploading an new version for an existing package (aka existing metadata)
It did issue an PUT to the already existing maven-metadata.xml, not some new one.
Maybe there was an misunderstanding, I am not talking about an SNAPSHOT maven-metadata, I already read this is not really supported, I mean the main metadata (the "artifact metadata") that lists all normal (release/latest) versions which are available within the package.

I could not figure out how to sniff at the HTTPS traffic, so I tried HTTP, but each request is just responded to with an redirect to the corresponding HTTPS URL, so I can not see what GitHub respond to this PUT request.
But the fact that Gradle does not try again but instead continues with the next file (the checksums) tells me that it succeeded with the request, or ignored the error.

My project is about writing an fully functional build system like gradle (although probably way simplified) for managing some projects in which I usually would have to mix different build systems (like Java JNI projects that contain native code).

From my understanding, the maven-metadata.xml (the artifact one, not the SNAPSHOT one) is not strictly necessary to upload and download artifacts from an repository, but instead is used to be able to list the available versions.
Would it be fine to just make my build system ignore an error when uploading the metadata and just leave it as is, containing only the first ever version published ?

That would (from my understanding) not comply with the maven specification, but I guess the immutable nature of GitHub Packages already does not comply.
I am no professional with maven tough, in fact, all I know about it comes from years using gradle and reading the maven documentation for implementing my own build system.

[M-Marvin]

I just tried to download the maven-metadata from one of my existing packages, to which I already published multiple versions.
And it seems like the maven-metadata there was in fact updated by gradle.
So it seems like it is possible somehow.

I did by the way also check if maybe github automatically updates the metadata after publishing the new artifacts, but no, it does not.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬