HTTPS clone URL
Subversion checkout URL
Clone this wiki locally
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 to use, by making it convenient enough that it's almost more work not to. :-)
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)
- ClojureSphere — Browse the open-source Clojure ecosystem (auto-generated)
/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:
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.
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.
See the mailing list discussion for more details.
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.
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 the #leiningen channel on irc.freenode.org.
Hosting of the releases.clojars.org repository on S3 is sponsored by Heroku.
See Contact for the current caretakers of the clojars.org server.
Deletion of jars is discouraged as you may break other's builds. If you're sure nobody is using your jar or 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.
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 #9.
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.
How does Clojars compare to Central?
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 a future separate Clojars "releases" repository might to some extent.
- 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.