Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Clojars is a community maintained repository for open source Clojure libraries.
How do I delete a jar?
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 GitHub project. 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 issue #616.
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.
How do I find libraries?
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)
Can I show the latest version on my project page?
/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:
What is the legal format for a group or project name?
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.
What is the legal format for a version?
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.
Why can't I deploy something that uses a group & artifact name that exists on Maven Central?
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.
Why can't I redeploy a non-SNAPSHOT version?
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.
What do I do if someone's taken my group name?
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.
We recommend you choose unique, creative names for your projects and release them to a public repository early and often.
Who looks after Clojars?
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.
Can I run my own repository using clojars-web?
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.
Do I have to use Leiningen with Clojars and Clojars with Leiningen?
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 and lightweight, automated procedures. 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 disagree with Central's naming recommendations (new version). See Groups for ours.
- 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.