Clojars is a community maintained repository for open source Clojure libraries.

Our goal is to encourage authors to make their projects available for automation tools like Leiningen or Boot to use, by making it convenient enough that it's almost more work not to. :-)

We will delete JARs for two reasons:

• There is a security vulnerability in a published JAR, i.e. malicious code
• Private credentials or code have been published

Deletion of entire projects or particular versions is discouraged as you will break anyone's build that depends on the project or version. There is also a cost associated with deletion, as it requires an admin's time. If you absolutely must remove it open an issue against the Clojars Administration GitHub repo. If you need it done privately contact the server caretakers. Before doing so, push a new revision with "Delete me" in the description in order to prove you're the owner of the project. We try to respond promptly to delete requests, but note that there may be a delay of several days if the request isn't security related.

If you just want to mark your project deprecated push a new version with the prefix "DEPRECATED: " in the description in your project.clj or POM.

If you'd like to discuss the policy or implement an alternative mechanism see discusion #818.

N.B. If you have published private credentials, you should consider them to be compromised immediately and rotate them. The Clojars download stats are not calculated in real-time, and do not include mirrors or rsync's, so a 0 download count does not indicate no-one has downloaded it.

If you know the name of the project you're looking for, Clojars provides a basic search box. Offline search indexes are also available for searching from tools like Leiningen and Eclipse.

If you don't know what you're looking for we recommend these resources:

• Clojure Toolbox — A categorised directory of libraries and tools (manually curated)
• Library Directory at clojure-doc.org — A categorised and annotated directory of libraries (manually curated)

Add /latest-version.svg to the end of the project page URL and embed it as an image.

For example in a Markdown README.md use this:

![](https://clojars.org/compojure/latest-version.svg)

Yes, you can control this by visiting the page for the group when logged in to Clojars as a group administrator. If active, a group member will get the following message if they try to deploy and don't have two-factor auth active on their account:

The group '<groupname>' requires you to have two-factor auth enabled to deploy.

Project and group names must consist solely of ASCII lowercase letters, numbers, hyphens, and underscores, and are checked against #"^[a-z0-9_.-]+$". This is at least as restrictive the standard Maven naming conventions, but is tighter to support a wide range of tooling and to support non-Unicode systems.

Version strings must consist solely of ASCII letters, numbers, dots, pluses, hyphens, and underscores, and are checked against #"^[a-zA-Z0-9_.+-]+$". The reasons for these restrictions are the same as our group/artifact restrictions.

Clojars no longer allows deployments that shadow artifacts in Maven Central. Allowing them is a security hole - depending on the order of the repositories a user is using, it may be possible that the version from Clojars is downloaded instead of the one from Maven Central. And since Clojars doesn't verify that accounts actually own the domain for the group they are deploying, it would be possible for someone to use Clojars as a vector for delivering a compromised artifact in place of one provided by Maven Central. Since you can't build Clojure projects without Maven Central (or a mirror of it) in your repositories (primarily because Clojure itself is distributed via Maven Central), there's no need to deploy artifacts to both repositories.

Once a non-SNAPSHOT version has been deployed, it is immutable (barring a valid deletion request). This allows repeatability, since it's safe to assume that every locally-cached copy of the version is identical. Note that we strive to make deployments atomic, so in the case of a timeout or network error during deployment, you should be able to redeploy, since the previous deployment shouldn't have been copied to the actual repo.

See the mailing list discussion for more details.

Clojars attempts to show links to the VCS host in two places on a project page:

• A link to the repository in the top left
• A link to the git tree for release in the top right

Both of these values are derived from the <scm> element in the POM file. The repository link comes from the <url> element within <scm>, and the git tree link uses that url along with the value from the <tag> element (note that tag is a bit of a misnomer; the tag can be a git tag or a SHA).

For example, an SCM block like:

<scm>
  <url>https://github.com/clojars/clojars-web/</url>
  <tag>f5480c4f964010a12dfbba5394ac413634c868c5</tag>
</scm>

Would result in Clojars using a repository url of https://github.com/clojars/clojars-web/ and a git tree url of https://github.com/clojars/clojars-web/tree/f5480c4f964010a12dfbba5394ac413634c868c5.

Note that the url and tag values must not have any maven template replacement (example: "https://github.com/clojars/${project.artifactId}") or shell escapes (example: $(git rev-parse HEAD)) in them, since Clojars does not process any of these directives. Values that have these directives will just be ignored and not displayed.

You can add an SCM block to the generated pom.xml in your chosen build tool:

Leiningen has built-in support for extracting VCS host information for Git repositories. As long as the project lies at the root of the repository, the current commit hash and URL to the origin remote will be added automatically to the POM. However, if for some reason your project is set up differently, you may need to add some configuration:

:scm {
  ; If your remote is not called origin, both of the following will need to be set
  :name "git" 
  :url "https://example.com/user/repo"

  ; Set this to override the tag set automatically
  :tag "fedcba098765"

  ; Set this if the repo root directory is not the project directory
  :dir ".."
}

Run lein pom to output a POM and test your settings.

Firstly, try to contact them. Most of the time it's someone honestly trying to be helpful by deploying a project to a repository when there has been no official effort to do so. We encourage people to perform third-party packaging under a org.clojars.username group name precisely to avoid this situation but it's not possible for us to enforce it. If you're unable to find any contact details contact the caretakers and we'll forward your message to the email address the user registered with.

If you don't get a response or if there is a dispute please open a ticket. If there is clear evidence that you are the owner of the canonical fork of your project then we will transfer ownership to you.

What counts as evidence is at the discretion of the caretakers on a case by case basis but we will typically look for factors such as:

• if the group id is based on a domain name and you demonstrate you are the owner of that domain
• if the project's canonical source repository (eg github) is under an account you can demonstrate you control
• copyright notices or documentation embedded in previous releases of a project with your name and email address

If there is no clear evidence of ownership or if it is contradictory we will leave the group unchanged. If there are two well known and long standing projects with the same name in dispute then we will leave the group unchanged.

If the issue is a trademark dispute, we will attempt to resolve it by discussion among all of the involved parties. If that fails, we will follow the advice of our legal counsel.

We recommend you choose unique, creative names for your projects and release them to a public repository early and often.

If you would like a name reserved because you own the project but never want it released on Clojars then open an issue to claim the group name.

Clojars is voluntarily maintained by individual community members and nobody works on it full time. If you'd like to get involved please join the clojars-maintainers mailing list. Discussions among maintainers also happen in #clojars on the Clojurians Slack.

See Contact for the current caretakers of the clojars.org server.

Certainly! Some people do. If it's publicly accessible please be sure to change the about text, logo, site name and contact link though to prevent confusion. You might also like to look at Nexus or Archiva.

Not at all. Clojars can be used with any tools that support the de facto standard Maven 2 repository layout.

Leiningen can be used with any Maven 2 style repository including Central and private repositories. See the Leiningen deploy guide.

There is a strong collaboration between the Leiningen and Clojars projects and they were born at the same time but they're intentionally complementary not coupled.

Central targets the broader JVM ecosystem and is stewarded by Sonatype. It aggregates the repositories of large projects like Apache and Codehaus and Sonatype's OSSRH for smaller projects. Central has stricter quality standards and a manual approval process. Central has a lot more infrastructure and resources.

Clojars is focused specifically on the Clojure community and is designed to have a low barrier to entry, but does have a manual group verification process. It is voluntarily supported by individuals.

Clojars is not designed to replace or compete with Central. I'd encourage companies, larger projects and anyone who wants to target the wider JVM ecosystem to upload to Central not Clojars. The easiest way to do that is via Sonatype's OSSRH.

If you find the process of releasing to Central confusing and onerous, Clojars may be more to your taste.

Policy differences from Central's:

• We don't currently enforce jar signing or metadata requirements, but may in the future.
• We don't perform manual policing or curation of the repository as we don't want to take on the role of a central authority. We believe it's your responsibility to decide which projects you trust. We would like to see a future with tools that make decentralized trust models more workable and convenient.

For organisations that want an offline copy of artifacts try using a caching repository proxy like Nexus or Archiva.

If you'd like to contribute a public mirror for low-latency and durability reasons post to the clojars-maintainers list. See also: Data