<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->

<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->

<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->

<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->

−

* Fedora 18 now ships a more complete Clojure programming stack, including the build tool Leiningen and key frameworks necessary for web application development. Developers can now use Clojure out-of-the-box without pulling dependencies from Internet repositories, saving both network bandwith, time and disk space.

+

* Fedora 18 now ships a more complete Clojure programming stack, including the build tool Leiningen. This will make it easier to package other Clojure libraries in the future.

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.

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.

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.

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.

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.