Maven Central requires coordinates (group, artifact, version), complete POM metadata, a sources jar and a javadoc jar for each jar, checksum files, and a PGP signature file for every deployed file. The version cannot be a SNAPSHOT. Use this list before your first release.
Requirements in one table
| Area | What Sonatype's page requires |
|---|---|
| Coordinates | groupId, artifactId, version. The version cannot end in -SNAPSHOT. Set packaging explicitly unless it is the default jar |
| POM metadata | name, description, url, at least one license, developers, and scm with connection, developerConnection and url |
| Dependencies | Strongly recommended to declare them. Repository declarations are discouraged |
| Extra jars | A sources jar and a javadoc jar for each non pom jar. Placeholder jars are allowed if you cannot provide real ones |
| Checksums | Hex encoded .md5 and .sha1 for each deployed file. .sha256 and .sha512 are optional |
| Signatures | A matching .asc signature for each deployed file. Signature files do not need checksums, and checksum files do not need signatures |
The page says the SCM URL can be private or a placeholder. It does not cover public key distribution or Central Portal tokens, so read the signing and portal documentation for those.
Why these checks exist
Metadata and signatures make a library traceable. A user can see who claims to have written it, where the source lives and whether the files match a signature. None of that proves the code is safe, but it raises the bar for a drive by upload.
Steps for a first release
- Choose a group ID you can prove you control. Use a domain you own or a hosting namespace the portal accepts.
- Fill in the POM metadata, including a real license.
- Build the sources and javadoc jars. If javadoc is hard for your project, a placeholder with a README pointing to the project is allowed.
- Create a signing key and protect it. See GPG keys or Sigstore, how a small project should sign releases and where to keep code signing keys.
- Generate checksums and signatures through your build tool.
- Upload through the Central Portal and check the validation result.
- After release, verify the artifacts as a user would.
After you publish
Plan to fix problems by releasing a new version rather than expecting to replace a published one, and check Sonatype's current policy on removals. See unpublish, yank, deprecate compared for how registries differ. Keep your dependencies current and tell users about security fixes with a clear note: what a security release note should say.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the dependency inventory and see how direct and transitive libraries are listed. That is the list your POM should describe honestly.
Safeguard generates SBOMs and scans Java dependencies; try the free scan at gold.safeguard.sh/scan.
Quick check
Do I need both MD5 and SHA-1 checksums?
The page lists hex encoded .md5 and .sha1 files as required, and .sha256 and .sha512 as optional.
Can I skip javadoc for a small library?
You still need a javadoc jar, but the page allows a placeholder with a README if you cannot provide real documentation.
Sources
Last reviewed: 19 October 2026.
