Clojure: what the clojure/clojure repository actually contains, and how to build it

What clojure/clojure is, and who the repository is for

The repository is the implementation of the Clojure programming language, written primarily in Java. The readme.txt opens with a copyright notice for Rich Hickey and states that use and distribution are covered by the Eclipse Public License 1.0, found in epl-v10.html at the root of the distribution. That single line tells you what kind of project this is: a language distribution, not an application.

The people who clone it fall into two groups. The first needs to work on the language: changing the reader, the compiler, or a core function, then running the test suite. The second wants a standalone jar built from source, which the README covers with a Maven profile. Neither group is the typical Clojure user. Someone who wants to write Clojure code should read the getting-started guide the README links to at clojure.org, because the repository README documents how to build the language, not how to install it for daily work. That split is the most important thing to understand before cloning.

The compiler, src/, test/ and codegen/ layout

The top-level entries are a map of how the language is put together. The src/ directory holds the implementation, test/ holds the test suite, and codegen/ is separate from both. The README does not say what codegen/ contains.

build.xml and antsetup.sh show that an Ant build path exists in the repository alongside pom.xml. The README does not document the Ant workflow, only the Maven one, so a contributor following the README will use Maven regardless of what the older files suggest. The doc/ directory and changes.md are the in-repository documentation surface; the repository has no published releases, so the changelog file is the concrete record to read when you want to know what moved between versions.

One dependency is called out explicitly in the README: the ASM bytecode engineering library, distributed under a three-clause BSD notice reproduced in the file. A compiler that emits JVM bytecode needs a bytecode manipulation library, and ASM is the one this project ships with. The README also reproduces the Apache License 2.0 text for the Guava Murmur3 hash implementation. Both notices sit in the same file as the EPL 1.0 notice, which is why the licence question for this repository is less simple than a single identifier.

Building Clojure from source with Maven

The README gives Maven as the local build path. Every command below is copied from it. Run the test suite first; it is the documented way to check that your checkout and toolchain agree before you change anything.

mvn test

A successful run means the tests in test/ passed against the source in src/. If you only want artifacts and not the test run, the README offers a skip flag.

mvn package -Dmaven.test.skip=true

Either package invocation writes JARs into target/. To put the build into your local Maven repository instead, the README gives mvn install. The standalone jar with dependencies included uses a profile named local.

mvn -Plocal -Dmaven.test.skip=true package

That produces clojure.jar, and the README shows how to start it.

java -jar clojure.jar

What you should see is a REPL prompt rather than an error about a missing main class. If the jar starts and you can evaluate an expression, the build is sound. Note what is absent: the README does not document rollback, does not mention any install script, and does not describe how to uninstall a locally installed artifact. Those steps are outside what this file covers.

Where the repository stops being the right tool

The README is a build document. It does not tell you how to install Clojure for normal development, and it does not describe an editor integration, a package manager workflow, or a project template. The getting-started link it provides points at clojure.org, which is where the project says to begin. If you follow only the repository README, you will end up with a jar you can run, and no guidance on how a Clojure project is normally structured.

There is a second boundary. Building from source ties you to a checkout of master rather than a released version. The repository was last pushed on 2026-10-27, so a build from master reflects whatever landed by that date, not a tagged release. If your goal is a reproducible dependency for an application, pulling a published artifact is the path the ecosystem expects, and this repository is the wrong entry point for that task.

A third limit is scope. Nothing in the README covers ClojureScript, which is a separate compiler and a separate repository.

Clojure against Java: the same runtime, a different starting point

The obvious alternative for a JVM team is Java itself. The difference is not the runtime, since Clojure compiles to JVM bytecode and depends on libraries like ASM to do it. The difference is where the language sits relative to the host. Java gives you a class-based object model, a static type system, and a compiler that is part of the platform you already install. Clojure gives you a source tree you can build with Maven, a REPL you reach with java -jar clojure.jar, and a licence file at the repository root rather than in a platform installer.

That changes adoption cost in a practical way. A Java team adds a JDK and a build tool. A team adopting Clojure adds a language artifact whose build the project documents as a Maven invocation, and whose day-to-day install path lives on clojure.org instead. Whether that is friction or freedom depends on whether you want to read the implementation. If you do, the Java-first source tree is an advantage; if you do not, it is overhead you never asked for.

Licence and the cost of tracking master

GitHub reports no licence identifier for the repository. The readme.txt states that use and distribution are covered by the Eclipse Public License 1.0, available in epl-v10.html at the root, and then reproduces a BSD-style notice for ASM and the full Apache License 2.0 text for the Guava Murmur3 hash implementation. Three licence texts in one file is a fact your legal review will want to see. Treat the EPL 1.0 reference as the primary statement and the bundled notices as the terms attached to the bundled components.

Upgrade cost follows from the same structure. The repository has no published GitHub releases, so the upgrade signal available to a reader is changes.md and the commit history on master. The last push was on 2026-10-27. A team that builds from source and deploys the resulting jar owns the task of reading changes.md before each rebuild; a team that depends on a published artifact delegates that reading to whoever publishes it. The README does not describe a versioning or support policy, so do not assume one exists.

Editorial conclusion

Adopt the clojure/clojure repository if you need to read or patch the language implementation itself, or you want a standalone jar built from source; the README's Maven targets are the documented path for that. Do not adopt it as your first step into Clojure: the getting-started guide at clojure.org is where the project points new users, and installing the language is a different task from building its source. Before committing, verify the toolchain by running mvn test against a clean checkout and confirming that the epl-v10.html file at the repository root is the licence text your legal review needs.

Frequently asked questions

Official sources

1. clojure/clojure on GitHub
2. Issues
3. Project website
4. README