Clojure

Summary

Currently Fedora ships a Clojure RPM, but does not ship tooling packages (e.g. the Leiningen build tool) or any of the commonly-used libraries (e.g. the Noir web framework, Korma SQL abstraction layer). We aim to rectify this situation and make Fedora a useful developer platform for Clojure out of the box.

Current status

Detailed Description

Clojure projects are generally managed and built using a tool called Leiningen, which uses the same repository layout as Maven (and comes with a build target for converting Leiningen project descriptors to Maven POM files).

For Fedora 18, our goal is to have a functioning Leiningen package that is functionally equivalent to the version downloadable from upstream, but packaged according to Fedora guidelines (in particular, depending on system libraries rather than bundling its own copies). This involves first ensuring its dependencies are packaged, and catch packaging errors in the Clojure package that is exposed by attempting to use it for building Leiningen.

Later, we would aim to make our Leinigen installation useful out-of-the-box for building RPM packages (similar to how JPackage provides mvn-rpmpackage), by making sure that Leiningen is configured out-of-the-box so it can use the system Maven repository. We expect to work on this concurrently with the work on packaging key Clojure libraries and frameworks, e.g. Korma and Noir.

Benefit to Fedora

Clojure is a Lisp programming language for the Java platform, and is one of the most popular alternative languages on the JVM. Its development process is remarkably Unix-friendly - the editor of choice is Emacs, many of the developers use Macs or Linux distributions, and the packaging quality is remarkably high w.r.t. not bundling libraries and using sane build management tools.

We currently only ship the core Clojure language itself, without the build tool (Leiningen) or any of the libraries; as it is, our distribution is not really suitable for Clojure development, beyond serving as a platform on which to bootstrap everything from Maven/Leiningen repositories. The Clojure package is also suffering from neglect - packaging mistakes do not get caught because no other package uses it as a dependency.

Scope

Changes are isolated and should not affect other parts of the distribution. Here is our current work plan:

Ensure that the default Leiningen project templates refer to the packaged versions of Clojure libraries

Package Clojure frameworks

Create a packaging guideline for Clojure packages

How To Test

Install Leiningen using yum. Then use it to create a new project, verifying that dependency resolution, compiling and testing work as expected.

User Experience

Using our Leiningen RPM instead of the one from upstream, the only noticeable difference should be that Leiningen would get more of its dependencies from the system Maven repository, resulting in less network access and thus a faster response. If the system is used by multiple developers, there is also a space saving as each developer wouldn't have duplicate copies of the same JAR packages in their personal Maven repositories.

Dependencies

None

Contingency Plan

Clojure is not currently being used in any part of the infrastructure, and thus there is no necessary contingency plan - even an incomplete feature would be an improvement over the baseline we currently have.