Liking cljdoc? Tell your friends :D

License’s missing piece

  1. Add Clojars Project to your deps.edn:

    :aliases {;;; Tools
              :build {:deps       {com.github.gnl/build.simple {:mvn/version "x.x.x"}}
                      :ns-default build.simple.core}}
  2. Create a project.edn file in your project’s root directory

  3. Install Maven 3.x+ (build.simple uses it for deployment), and configure it to get the Clojars (or other repository) credentials from the environment:

    <?xml version="1.0" encoding="UTF-8"?>
    <settings xmlns=""
  4. clj -T:build [install|deploy|jar|pom|clean] [:check false] [:sign false]

When deploying a non-snapshot artifact, deploy performs a number of sanity checks by default (clean working directory, correct git version tag, etc.), and signs it. It securely prompts for repository credentials as needed, and passes them to Maven via the environment; GPG-signing and passphrase handling are fully delegated to gpg-agent (you should probably use a graphical pinentry interface for this to work reliably).
If you have special requirements, build.simple can be a good starting point or foundation for rolling your own solution – feel free to call into it from your code and add your own keys to project.edn if you just want to add some minor functionality on top without writing everything from scratch.


While I consider to be an improvement in a number of ways – straightforward dependency resolution, no implicit behaviour/magic profiles, greater flexibility – I do miss Leiningen’s easy basic workflow of 1. bump version/edit metadata in project.clj → 2. lein install jar locally for testing → 3. lein deploy clojars.

Performing the same tasks with involves some combination of: creating and editing a verbose pom.xml template file (before 0.9.6’s :pom-data, anyway); syncing dependencies from deps.edn; choosing between multiple separate solutions for deployment, most of which handle the GPG and/or Clojars credentials in various rather convoluted and insecure ways; directly calling Maven; and writing some code to tie it all together.

I have no intention of reinventing Leiningen here, and am inclined to view the project as more or less feature-complete. build.simple is meant to cover the 95% use case of a library author, and I would generally recommend using directly for anything else.

Similar projects

  • liquidz/build.edn has been around for quite a bit longer and takes a very similar approach to making the experience more pleasant. I wasn’t aware of it when I wrote and released build.simple. build.edn has more features, more configurability, more (relative) complexity, a non-prompting approach to credentials handling, and no artifact signing (at the time of writing.)

Copyright (c) 2023 George Lipov
Licensed under the Eclipse Public License 2.0

Can you improve this documentation?Edit on GitHub

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close