Clojure Q&A - Recent questions tagged tools.build

How to access non-jar artifacts (aar, zip) downloaded via tools.deps in build.clj?

Wed, 24 Dec 2025 08:55:46 +0000

I want to access an aar/zip artifact in build.clj that's already downloaded via deps.edn:

{:deps
 {com.newrelic.agent.android/android-agent {:local/root "build/jars/android-agent.jar"
                                            :doc        "extracted from aar"}
  com.newrelic.agent.java/newrelic-api     {:local/root "build/jars/newrelic-api.jar"
                                            :doc        "extracted from newrelic-java.zip"}}
 :aliases
 {:build {:deps       {io.github.clojure/tools.build            {:mvn/version "0.10.11"}
                       com.newrelic.agent.java/newrelic-java    {:mvn/version "8.25.1"
                                                                 :extension   "zip"}
                       com.newrelic.agent.android/android-agent {:mvn/version "7.6.14"
                                                                 :extension   "aar"}}
          :ns-default build}}}

In build.clj I need to unpack this zip and extract a jar from it.
And I don't have to hardcode .m2 paths or duplicate the version.

How can it be done?

See https://github.com/clojure/tools.deps/blob/46661e929ab702d0ee532188edb58d06b39cef6c/src/main/clojure/clojure/tools/deps/extensions/maven.clj#L172

tools.build compile-clj capture out/err

Mon, 28 Jul 2025 19:41:29 +0000

When calling compile-clj, a user can pass in :out and :err to capture the output of the compilation call. However, if for some reason the sub-process exits with a non-0, compile-clj throws without returning that output, making it hard to know what went wrong. (see here: https://github.com/clojure/tools.build/blob/2d2f1b05fd84c3cc756221c17fcfb98034b4d65c/src/main/clojure/clojure/tools/build/tasks/compile_clj.clj#L120)

I would find it helpful if the ex-data of the thrown exception included the :out (variable ps-out and :err (variable ps-err) from the process/process call. Then I could have further insight into what went wrong.

`create-basis` silently accepts missing aliases

Tue, 10 Jun 2025 00:57:37 +0000

In this scenario, the alias for create-basis was incorrect, preventing security deps overrides from being applied. For 2 years clojars was deployed with these vulnerable deps.

In this case, I proposed to inline the alias into :deps. However there may be other scenarios where a tools.deps change might be helpful to catch these mistakes earlier, for example a warning or error.

How to ignore :src-pom default for clojure.tools.build.api/write-pom if ./pom.xml exists?

Sun, 31 Mar 2024 20:50:22 +0000

I have a project that generates more than one jar artifact. For project A, I have ./pom.xml that is used as a template and everything works fine.

For project B, I want to generate a pom.xml that's completely separate from project A which does not use ./pom.xml as a template. I generate the pom as follows:

(require '[clojure.tools.build.api :as b])
(b/write-pom {:class-dir class-dir
                  :pom-data pom-data
                  :lib coord
                  :version version
                  :basis basis})

However, since ./pom.xml exists, it is used as a template. Explicitly passing nil for :src-pom doesn't help. The only workaround I could find was to pass in a bogus path for :src-pom.

tools.build vs babashka as build tool

Mon, 22 Jan 2024 19:50:19 +0000

My understanding is that babashka is meant to be a fast startup clojure runtime, so they seem to work well together (borkdude already started porting tools.build to bb), but as I'm still a beginner, I wanted to understand how you folks think of those tools.

When should I consider one over the other, aside from what babashka already states in its repo (prefer jvm clojure for long running scripts)?

Thanks!

Is tools.build considering adding a :license argument?

Fri, 29 Sep 2023 17:17:01 +0000

Now that Clojars requires licenses, projects that need to go up there need a license block in the pom files of their jars. Using build.tools it's possible to create a pom.xml, manually edit it to include a license section, then create a jar using that pom. But, that's manual.

Are there plans to add an option for write-pom (and gen-pom) to allow programmatic insertion of a license?

tools.build.api/uber uses EDN for data_readers.cljc -- it should support reader conditionals

Tue, 07 Mar 2023 19:36:03 +0000

The conflict handler for data_readers.clj* treats the files as EDN when it reads them to merge them. This fails for .cljc files containing reader conditionals:

RuntimeException No dispatch macro for: ?
	clojure.lang.Util.runtimeException (Util.java:221)
	clojure.lang.EdnReader$DispatchReader.invoke (EdnReader.java:552)
	clojure.lang.EdnReader.readDelimitedList (EdnReader.java:757)
	clojure.lang.EdnReader$MapReader.invoke (EdnReader.java:680)
	clojure.lang.EdnReader.read (EdnReader.java:145)
	clojure.lang.EdnReader.read (EdnReader.java:111)
	clojure.lang.EdnReader.readString (EdnReader.java:67)
	clojure.edn/read-string (edn.clj:46)
	clojure.edn/read-string (edn.clj:37)
	clojure.edn/read-string (edn.clj:37)
	clojure.tools.build.tasks.uber/conflict-data-readers (uber.clj:89)
	clojure.tools.build.tasks.uber/conflict-data-readers (uber.clj:86)

Potential race condition in requiring-resolve?

Mon, 31 Oct 2022 05:20:05 +0000

Hello! I've been using a few of the functions from clojure.tools.build.api in a future and I sporadically see this error...

Execution error (IllegalStateException) at clojure.tools.build.api/create-basis (api.clj:154).
Attempting to call unbound fn: #'clojure.tools.build.tasks.create-basis/create-basis

From what I see in tools.build...

(defn create-basis
  ([]
   ((requiring-resolve 'clojure.tools.build.tasks.create-basis/create-basis)))
  ([params]
   ((requiring-resolve 'clojure.tools.build.tasks.create-basis/create-basis) params)))

...the code is only really using requiring-resolve to execute another function. Diving deeper into requiring-resolve I can see that the first call to resolve is not synchronized with the same lock that the serialized-require function uses...

(defn- serialized-require
  [& args]
  (locking clojure.lang.RT/REQUIRE_LOCK
    (apply require args)))

(defn requiring-resolve
  [sym]
  (if (qualified-symbol? sym)
    (or (resolve sym)
        (do (-> sym namespace symbol serialized-require)
            (resolve sym)))
    (throw (IllegalArgumentException. (str "Not a qualified symbol: " sym)))))

First, is it possible requiring-resolve is actually returning clojure.lang.Var$Unbound from the first call to resolve when another thread is in the process of requiring that namespace via serialized-require? Assuming so, should tools.build (and I guess by extension most Clojure code) avoid using the ((requiring-resolve 'some-other/function)) pattern? Is it possible requiring-resolve could be modified to be thread safe?

Thanks!

create-basis uses the wrong local maven repository

Sat, 24 Sep 2022 08:29:08 +0000

I am attempting to build a Clojure project with numerous dependencies and contain everything into a single folder. The reason for doing this is because I will eventually build this software in an environment where I am not permitted to modify the home folder.

The following command is being used
GITLIBS=/var/build/software/.gitlibs clojure -Srepro -Sdeps '{:mvn/local-repo "/var/build/software/.m2/repository"}' -T:build uber-aot

tools.deps is able to download all dependencies into the specified local repository. Once it's time for tools.build to run, I seem to get an error in the middle of a call to b/create-basis. Here is what the error looks like.

Execution error (FileNotFoundException) at java.io.RandomAccessFile/open0 (RandomAccessFile.java:-2). /home/user/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.pom.part.lock (No such file or directory)

Is there any way to pass in the local Maven repository to tools.build? Preferably in the command line.

tools.build git-process returns null when run on Windows.

Sat, 10 Sep 2022 20:03:55 +0000

I have this clojure code in my tools/build.clj file:

(ns build
  (:require [clojure.tools.build.api :as build]))
;; Get the number of commits reachable since the last tagged commit.
(def version
  (let [last-tag (build/git-process {:git-args "describe --tags --abbrev=0"})]
    (format "%s.%s"
            last-tag
            (build/git-process {:git-args
                                ["rev-list"
                                 (format "%s..HEAD"
                                         last-tag)
                                 "--count"]}))))

This sets the version string to null.null when run on Windows, but not when run on Linux. Thought you'd want to know.

Ability to customise java-cmd in tools.build

Sat, 27 Aug 2022 20:54:32 +0000

Moving the original question from Clojurians Slack:

When moving one of my projects to JDK 19 I was pointing clojure to the jdk using the JAVA_CMD env var. Everything was fine til I hit the uber jar step in the CI, where it simply refused to recognise the jdk 19 functions.

Took me a while and including reading the tools.build source to realise why it wasn't propagating the JAVA_CMD var and turns out I had to read env and send the :java_cmd in the b/compile-clj call.

I can see why the behaviour is like this, but would :java_cmd defaulting to the value of JAVA_CMD something that could be considered? Feels a bit more intuitive for me, as mostly the invocations of tools.build fns would be from the shell.

Exception in EdnReader$DispatchReader

Sat, 25 Jun 2022 16:32:02 +0000

(from https://clojurians.slack.com/archives/C02B5GHQWP4/p1656165951371179)
When I include tick/tick {:mvn/version "0.5.0-RC6"} as a dep, I get the exception below. I cannot reproduce in an deps.edn that only contains this library so I believe there is some kind of conflict with another library.

{:clojure.main/message
"Execution error at clojure.tools.build.tasks.uber/conflict-data-readers (uber.clj:90).\nNo dispatch macro for: ?\n",
:clojure.main/triage
{:clojure.error/class java.lang.RuntimeException,
:clojure.error/line 90,
:clojure.error/cause "No dispatch macro for: ?",
:clojure.error/symbol
clojure.tools.build.tasks.uber/conflict-data-readers,
:clojure.error/source "uber.clj",
:clojure.error/phase :execution},
:clojure.main/trace
{:via
[{:type java.lang.RuntimeException,

:message "No dispatch macro for: ?",
:at [clojure.lang.Util runtimeException "Util.java" 221]}],

:trace
[[clojure.lang.Util runtimeException "Util.java" 221]
[clojure.lang.EdnReader$DispatchReader invoke "EdnReader.java" 552]
[clojure.lang.EdnReader readDelimitedList "EdnReader.java" 757]
[clojure.lang.EdnReader$MapReader invoke "EdnReader.java" 680]
[clojure.lang.EdnReader read "EdnReader.java" 145]
[clojure.lang.EdnReader read "EdnReader.java" 111]
[clojure.lang.EdnReader readString "EdnReader.java" 67]
[clojure.edn$read_string invokeStatic "edn.clj" 46]
[clojure.edn$read_string invokeStatic "edn.clj" 37]
[clojure.edn$read_string invoke "edn.clj" 37]
[clojure.tools.build.tasks.uber$conflict_data_readers

invokeStatic
"uber.clj"
90]

[clojure.tools.build.tasks.uber$conflict_data_readers

invoke
"uber.clj"
86]

[clojure.tools.build.tasks.uber$handle_conflict

invokeStatic
"uber.clj"
120]

[clojure.tools.build.tasks.uber$handle_conflict

invoke
"uber.clj"
111]

[clojure.tools.build.tasks.uber$explode invokeStatic "uber.clj" 157]
[clojure.tools.build.tasks.uber$explode invoke "uber.clj" 137]
[clojure.tools.build.tasks.uber$uber$fn3537$fn3541

invoke
"uber.clj"
253]

[clojure.lang.PersistentVector reduce "PersistentVector.java" 343]
[clojure.core$reduce invokeStatic "core.clj" 6885]
[clojure.core$reduce invoke "core.clj" 6868]
[clojure.tools.build.tasks.uber$uber$fn__3537 invoke "uber.clj" 252]
[clojure.core.protocols$iter_reduce invokeStatic "protocols.clj" 49]
[clojure.core.protocols$fn__8230 invokeStatic "protocols.clj" 75]
[clojure.core.protocols$fn__8230 invoke "protocols.clj" 75]
[clojure.core.protocols$fn8178$G8173__8191

invoke
"protocols.clj"
13]

[clojure.core$reduce invokeStatic "core.clj" 6886]
[clojure.core$reduce invoke "core.clj" 6868]
[clojure.tools.build.tasks.uber$uber invokeStatic "uber.clj" 250]
[clojure.tools.build.tasks.uber$uber invoke "uber.clj" 237]
[clojure.lang.Var invoke "Var.java" 384]
[clojure.tools.build.api$uber invokeStatic "api.clj" 480]
[clojure.tools.build.api$uber invoke "api.clj" 408]
[org.corfield.build$uber invokeStatic "build.clj" 250]
[org.corfield.build$uber invoke "build.clj" 208]
[build$uber invokeStatic "build.clj" 14]
[build$uber invoke "build.clj" 12]
[clojure.lang.AFn applyToHelper "AFn.java" 154]
[clojure.lang.AFn applyTo "AFn.java" 144]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.core$apply invokeStatic "core.clj" 667]
[clojure.core$apply invoke "core.clj" 662]
[clojure.run.exec$exec invokeStatic "exec.clj" 48]
[clojure.run.exec$exec doInvoke "exec.clj" 39]
[clojure.lang.RestFn invoke "RestFn.java" 423]
[clojure.run.exec$_main$fn__205 invoke "exec.clj" 180]
[clojure.run.exec$_main invokeStatic "exec.clj" 176]
[clojure.run.exec$_main doInvoke "exec.clj" 139]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.core$apply invokeStatic "core.clj" 667]
[clojure.main$main_opt invokeStatic "main.clj" 514]
[clojure.main$main_opt invoke "main.clj" 510]
[clojure.main$main invokeStatic "main.clj" 664]
[clojure.main$main doInvoke "main.clj" 616]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.main main "main.java" 40]],
:cause "No dispatch macro for: ?"}}

relative directories in classpath-roots

Sun, 19 Jun 2022 16:50:53 +0000

In the context of a monorepo containing several modules I have noticed an issue with clojure.tools.build.api/compile-clj which is making difficult to compile files when the basis project root is not in the current directory.

Here is a minimal scenario demonstrating the problem.

I have a top-level monorepo deps.edn using tools.build to prepare/package its modules

 {:deps {monorepo/module-a {:local/root "modules/a"}}
 :aliases {:build {:deps {io.github.clojure/tools.build {:git/tag "v0.8.2"
                                                         :git/sha "ba1a2bf"}}
                   :ns-default build}}}

Module A contains some clojure source files. Here is modules/a/deps.edn

{:paths ["src"]}

Those files require a compilation step. Here is the top-level build.clj file expected to proccess those files.

(ns build
  (:require [clojure.tools.build.api :as b]))

(def module-a (binding [b/*project-root* "modules/a"]
                (b/create-basis {:project "deps.edn"})))

(defn compile-a [_]
  (b/compile-clj
   {:basis module-a
    :src-dirs ["modules/a/src"]
    :class-dir "target/module-a/classes"}))

However when invoking clojure -T:build compile-a from top-level directory I encounter the following error

Execution error (FileNotFoundException) at user/eval136$fn (compile.clj:5).
Could not locate monorepo/module/a__init.class, monorepo/module/a.clj or monorepo/module/a.cljc on classpath.

The problem is that the "src" relative directory is not expanded in the :classpath-roots which lead compile-clj to search source files in the wrong location. It is possible to work around the issue by binding the *project-root* again and adapting :src-dirs and class-dir relative to module A root directory like this

(defn compile-a [_]
  (binding [b/*project-root* "modules/a"]
    (b/compile-clj
     {:basis module-a
      :src-dirs ["src"]
      :class-dir "../../target/module-a/classes"})))

However IMO it would be better if the computed classpath in the basis was fully expanded by transforming relative paths into absolute ones to avoid this extra ceremony.

What do you think?
Is there a reason why relative source path directories are currently kept relative ?

Can tools.build be configured to compile directly to project target?

Mon, 23 May 2022 21:38:43 +0000

I’m hitting a performance bottleneck when AOT-compiling my large project with clojure.tools.build.tasks.compile-clj/compile-clj. I narrowed the problem down to clojure.tools.build.util.file/copy-contents, it spends about 5 minutes copying my roughly 35k class files from working directory to target/classes.

We don't really need this indirection as we clean our target folder each time we start the process, we would be fine with compiling directly to target. Could that be introduced as an option?

Files in deps :local/root :git/url will directly copy into uberjar without go through conflict-handlers

Fri, 22 Apr 2022 10:58:50 +0000

https://github.com/clojure/tools.build/blob/1309f935b098123eb807c972a053eeab77f6f4cd/src/main/clojure/clojure/tools/build/tasks/uber.clj#L172

The handling between jar and lib folders like git deps or local root are completely different. In my case, I have some config files in edn format (duct's duct_hierarchy.edn) exists in both jar deps and git deps. My additional conflict handler is never receiving the edn file that exists in git deps.

Is it the expected behaviour? I can imagine that even LICENSE or data_readers.clj would suffer the same issue. e.g. being overrided by files in git deps.

(re-)building without internet access (with nix)

Fri, 18 Mar 2022 03:22:19 +0000

When building something that depends on tools.build, I expect to be able to build once, which fetches all the required dependencies, and then build again without internet access.

In particular, I'd like to be able to fetch all those dependencies separately and then build from inside a nix build.

This works in clojure 1.10.3.855, but breaks in 1.10.3.933, and I'm not sure why.

You can find a reproducible repo at https://github.com/radvendii/clojure-tools.build-test, with instructions in the readme.

Is it possible to set a var during compilation in tools.build?

Mon, 28 Feb 2022 20:50:43 +0000

Specifically I'd like to set clojure.test/*load-tests* to false, so that test code is excluded by the clojure.test/deftest,with-test etc. macro's. Lein provided injections as an escape hatch, tools.build doesn't seem to have an equivalent.

Looking at the code, tools.build seems to compile code from a separate generated script in a temp file, which seems to make injections or wrappers impossible. Also couldn't find options to pass other than compiler options.

A more in-depth description of this use case can be found on clojureverse: https://clojureverse.org/t/require-import-inside-deftest/8644/3

Is there a solution or suggested workaround available?

tools.build/javac does not handle modules-info

Sun, 02 Jan 2022 15:54:15 +0000

Attempting to compile a modular Java project will fail, reporting that it cannot not find the required modules.

I fixed it by adding the module paths manually in :javac-opts. Could tools.build handle this? Either by adding all the modules to the module path, or ignoring module-info.java and module-info.class. tools.build/javac will also fail if there is a module-info.class in the classes directory and tools.build/javac does not find the modules.

Thank you.

tools.build/jar doesn't support "sections" in manifest

Sun, 05 Dec 2021 14:52:52 +0000

Sections are groups which start with Name: and have section-specific entries in them.

Capsule uses this for having platform-specific information about how to start.

Here's an example of using the API to get section information:

Main-Class: clojure.main

Name: Frank
Main-Class: frank.clojure.main

and

❯ clj       
Clojure 1.10.3
user=> (require '[clojure.java.io :as io])
nil
user=> (io/input-stream "/tmp/MANIFEST.MF")
#object[java.io.BufferedInputStream 0x69ce2f62 "java.io.BufferedInputStream@69ce2f62"]
user=> (def mf (java.util.jar.Manifest. (io/input-stream "/tmp/MANIFEST.MF")))
#'user/mf
user=> (.getAttributes mf "Frank")
{#object[java.util.jar.Attributes$Name 0x2e3a5237 "Main-Class"] "frank.clojure.main"}
user=> (.getMainAttributes mf)
{#object[java.util.jar.Attributes$Name 0x2e3a5237 "Main-Class"] "clojure.main"}
user=> (.getEntries mf)
{"Frank" {#object[java.util.jar.Attributes$Name 0x2e3a5237 "Main-Class"] "frank.clojure.main"}}

tools.build copy-dir with replace loses file permissions

Fri, 03 Dec 2021 06:29:30 +0000

When you use clojure.tools.build.api/copy-dir with :replace it reads the source file and then writes a new target file -- it doesn't "copy" the file so the target file is created with default permissions.

This is a problem if you are copying executable shell scripts and trying to replace text in them because the target file created won't have executable permissions.

This cropped up with deps-new in this issue: https://github.com/seancorfield/deps-new/issues/22

I think that if you source file is executable, the target file should also be executable -- and that works fine without :replace.

Is it possible to build an uberwar using deps.edn using tools.build or other tool?

Thu, 02 Dec 2021 13:22:01 +0000

We have a small Clojure & ClojureScript web app running in Tomcat. The project managed to end up with a deps.edn for use with Shadow-cljs & lein for the backend to essentially build an uberwar. Is there a way to build an uberwar with tools-build or in some other way using deps.edn?

Thanks for any pointers

Cheers
Daniel Sunnerek

tools.build uber's default conflict handlers don't append to META-INF/services properly

Fri, 26 Nov 2021 17:29:12 +0000

Our project has some dependencies that register parsers for various file formats via the java services framework.

We’re using b/uber and are finding some META-INF/services/ definitions are not correctly being appended.

I’ve chased this down to the regex in the default-handlers being ^META-INF/services/ instead of something more like ^META-INF/services/.*

The current regex would match under re-find, but not under re-matches which the implementation uses.

tools.build: are "standard" build tasks under consideration?

Thu, 14 Oct 2021 21:40:27 +0000

What, if any, thought has been put into the idea of having "standard" build task names for tools.build-based builds?

This could be in the form of actual code in tools.build (or a layer on top of it), or simply an official, published convention. At this stage I'm more interested in whether the general concept is on the radar and if so what it might look like, and less concerned with implementation specifics.

This matters because while allowing authors to name their build tasks as they wish has some (small?) value to those authors, it results in a fragmented experience for the consumers of that build - a consumer cannot make any assumptions about each new tools.build based project they encounter that they wish to build themselves.

While humans can introspect a build script to figure out how to operate it, that's a lot more difficult for downstream build-based automation; including (but not limited to) systems such as jitpack.io, Heroku, etc.

Having started dabbling in tools.build, the current incarnation is feeling quite a bit like the Java build environment circa 2004 or so (right before Maven 1.0 was released). At that time Apache Ant was the dominant build tool, and every single Ant build script was a special snowflake that forced consumers to spend time studying before they could be used effectively. For all its substantial flaws, Maven 1.0 at least solved that one problem. While comparing tools.build to Apache Ant is clearly a massive disservice in many ways (tools.build's scripting language, composability, and dependency management pieces are clearly light-eons ahead of anything Ant ever had), the lack of a well-defined "interface" into tools.build-based build scripts has given me a strong feeling of déjà vu...

tools.build uber task fails when the dependency tree contains a dep which has no jar

Tue, 12 Oct 2021 14:00:42 +0000

The clojure.tools.build.api/uber task fails when the dependency tree contains a dep which has no jar.

A relatively minimal failing test case is the following tools.build task:

(ns build 
  (:require [clojure.tools.build.api :as b]))

(defn failing-uber [_]
    (b/uber {:class-dir "classes"
     :uber-file "foo.jar"
     :basis (b/create-basis {:project {:deps {'org.apache.jena/apache-jena-libs {:mvn/version "4.2.0" :extension "pom"} }}})})

(comment 
   (failing-uber {})
 )

Evaluating the above function results in the following exception:

1. Unhandled clojure.lang.ExceptionInfo
   Unexpected lib file:
   /Users/rick/.m2/repository/org/apache/jena/apache-jena-libs/4.2.0/apache-jena-libs-4.2.0.pom
   {}
                  uber.clj:  182  clojure.tools.build.tasks.uber/explode
                  uber.clj:  141  clojure.tools.build.tasks.uber/explode
                  uber.clj:  257  clojure.tools.build.tasks.uber/uber/fn/fn
     PersistentVector.java:  343  clojure.lang.PersistentVector/reduce
                  core.clj: 6829  clojure.core/reduce
                  core.clj: 6812  clojure.core/reduce
                  uber.clj:  256  clojure.tools.build.tasks.uber/uber/fn
             protocols.clj:   49  clojure.core.protocols/iter-reduce
             protocols.clj:   75  clojure.core.protocols/fn
             protocols.clj:   75  clojure.core.protocols/fn
             protocols.clj:   13  clojure.core.protocols/fn/G
                  core.clj: 6830  clojure.core/reduce
                  core.clj: 6812  clojure.core/reduce
                  uber.clj:  254  clojure.tools.build.tasks.uber/uber
                  uber.clj:  241  clojure.tools.build.tasks.uber/uber
                  Var.java:  384  clojure.lang.Var/invoke
                   api.clj:  394  clojure.tools.build.api/uber
                   api.clj:  339  clojure.tools.build.api/uber
                      REPL:   21  build/eval25043
                      REPL:   21  build/eval25043
             Compiler.java: 7181  clojure.lang.Compiler/eval
             Compiler.java: 7136  clojure.lang.Compiler/eval
                  core.clj: 3202  clojure.core/eval
                  core.clj: 3198  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj: 1977  clojure.core/with-bindings*
                  core.clj: 1977  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj:  662  clojure.core/apply
                regrow.clj:   20  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  825  java.lang.Thread/run

I believe this is because the above dependency has no corresponding jar file, and only contains a pom.xml which groups up a set of dependencies.

tools.build.api/copy-dir corrupts binary files if :replace is used

Sun, 10 Oct 2021 01:32:33 +0000

Without a :replace parameter, b/copy-dir faithfully copies over any binary (and text) files in from the source directories.

However, if a :replace parameter is provided, then it corrupts any binary files when copying. It does the replacement properly for any text files in the directories.

Repro:

Create a source dir mysrc. In that dir, place the file
cryogen.png from
https://raw.githubusercontent.com/cryogen-project/cryogen/master/src/leiningen/new/cryogen/img/cryogen.png
Then run (b/copy-dir :src-dirs ["mysrc"] :target-dir "newdir" :replace {"<<name>>" "me"})
The cryogen.png in newdir will be corrupted.

tools.build's compile-clj does not allow setting jvm options

Wed, 22 Sep 2021 14:03:32 +0000

I've a project that uses Malli with a custom default registry, a feature which requires the code be compiled with a certain jvm opt set as is detailed in its documentation.

It was suggested to me in this issue that this is currently not supported in tools.build's compile-clj function. I'm posting here in the hopes this can be filed as a feature request so that I can eventually move this project to tools.build.

Thanks.

Add git-branch function

Mon, 20 Sep 2021 22:31:14 +0000

This is useful for deciding whether to issue a SNAPSHOT release or not.

Here's a working implementation if anyone wants it for their project now:

(ns build
  (:require [clojure.string :as str]
            [clojure.tools.build.api :as b]
            [clojure.tools.build.api.specs :as specs]))

(defn git-branch
  "Shells out to git and returns the current branch
    git branch --show-current
  Options:
    :dir - dir to invoke this command from, by default current directory"
  [{:keys [dir] :or {dir "."} :as params}]
  (@#'b/assert-specs "git-branch" params :dir ::specs/path)
  (-> {:command-args ["git" "branch" "--show-current"]
       :dir (.getPath (b/resolve-path dir))
       :out :capture}
    b/process
    :out
    str/trim))

(def lib 'my-group/my-lib)

(def version
  (if (= "master" (git-branch nil))
    (format "1.0.%s" (b/git-count-revs nil))
    (format "1.0.%s-SNAPSHOT" (b/git-count-revs nil))))

Should tools.build functions respect with-dir (from tools.deps.alpha)?

Wed, 08 Sep 2021 22:02:10 +0000

I ran across this issue with depstar but observed that tools.build behaves the same, possibly incorrect, way.

See https://github.com/seancorfield/with-dir-repro

If you wrap (b/create-basis ..) in with-dir from tools.deps.alpha, it calculates the basis from the deps.edn file in the context of the with-dir location.

However, if you use that basis with tools.build functions, they do not behave correctly -- even if they are also wrapped in the same with-dir context.

The dependencies come from the project deps.edn (Clojure 1.9.0 in this example) but the src used is from the root of the repo, not from the project folder.

This is counter-intuitive (and took me a while to track down with depstar -- where I definitely consider it to be a bug).

tools.build.api/git-count-revs should support rev-lists path argument

Sun, 22 Aug 2021 10:20:03 +0000

Given a monorepo it's useful to have git-count-revs return only the revs affecting a particular folder.

Ie:

$ cd mymonorepo/service-a
$ git rev-list HEAD --count
1024 # all revs in monorepo
$ git rev-list HEAD --count -- .
17 # only count revs affecting service-a

tools.build.api/write-pom does not expose generated pom's filename

Sat, 21 Aug 2021 21:01:23 +0000

tools.build.api/write-pom writes a pom.xml file, but does not expose the file name.

Many tools that deploy to Clojars/Maven Central/etc. expect to be passed the name of a pom.xml file. For example cemerick.pomegranate.aether/deploy and deps-deploy.deps-deploy/deploy expect a :pom-file argument.

This leads to hard-coding this filename, for example in next-jdbc deps.edn, or re-calculating it, as in f-form dev/build.clj.

Would it be possible for tools.build to expose either the pom directory or pom filename, to facilitate the integration of builds and deploys?

How to control the transient deps that get compiled/assembled into an uberjar?

Thu, 05 Aug 2021 16:36:31 +0000

I am having trouble understanding how to control the contents of an uberjar using tools.build. In this scenario, the runtime environment (a Spark cluster) provides some deps and thus those deps should not be in the uberjar. Let's say I have 2 classpaths (represented as aliases):

:compile The classpath with all deps/classes that are required for compilation.
:uber The classpath with only the deps/classes that should be in the final jar.

In theory, if you take the :compile classpath and subtract the :uber classpath, we should get the set of classes that are provided by the runtime environment.

Consider the following simplified dependency graph:

We only need the blue deps to be in the jar. The white "provided" deps need to be used during compilation but should not be in the final uberjar.

I looked into using the :filter-nses option of compile-clj but it creates problems with transient deps.

If we filter to only my.project we will lose the important deps of some.other/dep and some.transient/dep.
If we filter to exclude org.apache (not possible with :filter-nses, but in theory it could be done) we would still have org.scala-lang/scala-library hanging around.

I also experimented using different calls to create-basis during compile and jar building. I'm not sure if that makes any sense.

Is it possible to leverage the dependency graph to control either 1) what gets compiled or 2) which classes get put into an uberjar? Any advice would be much appreciated.

create-basis/java-command do not handle :jvm-opts

Tue, 03 Aug 2021 04:31:20 +0000

I have a :test alias in my project, which includes :jvm-opts (as well as :extra-paths and :extra-deps). I call tools.build.api/create-basis with {:aliases [:test]} and then pass that basis to tools.build.api/java-command but that doesn't include those JVM options.

In order to pick up those JVM options, I needed to do this:

(defn run-tests
  [_]
  (let [basis    (b/create-basis {:aliases [:test]})
        combined (t/combine-aliases basis [:test])
        cmds     (b/java-command {:basis     basis
                                  :java-opts (:jvm-opts combined)
                                  :main      'clojure.main
                                  :main-args ["-m" "cognitect.test-runner"]})
        {:keys [exit]} (b/process cmds)]
    (when-not (zero? exit)
      (throw (ex-info "Tests failed" {})))))

(so I have to use tools.deps.alpha/combine-aliases).

Is this expected? Should this be easier?

tools.build.api/write-pom does not update scm>tag

Tue, 03 Aug 2021 03:41:09 +0000

Although write-pom updates the <version> field in the pom.xml, it does not attempt to update the <scm><tag> field. How should folks deal with that tag field when using tools.build?

tools.build create-basis cannot use alias that includes tools.deps.alpha

Mon, 26 Jul 2021 23:38:47 +0000

If you try to call create-basis with an alias that involves tools.deps.alpha, you get the following exception:

Execution error (ExceptionInfo) at clojure.tools.deps.alpha.extensions.maven/get-artifact (maven.clj:133).
Could not find artifact org.clojure:tools.deps.alpha:jar:${project.version} in central (https://repo1.maven.org/maven2/)

This is because tools.build includes a source version of deps.edn with that string, instead of a version number:

./tools.build/src/main/resources/clojure/tools/deps/deps.edn
    :deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "${project.version}"}}}

Here's the minimal repro: in an otherwise empty directory:

;; deps.edn 
{:aliases
 {:build
  {:deps {io.github.clojure/tools.build {:git/tag "v0.1.6" :git/sha "5636e61"}}
   :ns-default build}}}

;; build.clj 
(ns build
  (:require [clojure.tools.build.api :as b]))

(defn bug [_]
  (b/create-basis {:aliases [:deps]}))

Then run:

clojure -T:build bug

Given that tools.build already explicitly depends on t.d.a as follows, I don't understand why it also needs a copy of t.d.a's deps.edn source in in the resources tree?

org.clojure/tools.deps.alpha {:mvn/version "0.12.1003"}

Removing that file from the checked out tools.build (under ~/.gitlibs/libs) seems to solve the problem and doesn't appear to break anything else...

What does "Manifest type :jar not loaded when finding deps ..." mean?

Sun, 18 Jul 2021 06:16:17 +0000

I have a jar that I created from one of my projects using tools.build. I have included it has a :local/root dep in a different project but get the following error whenever I invoke clj with the jar on the classpath.

Error building classpath. Manifest type :jar not loaded when finding deps for io.github.erp12/clark-scala in coordinate {:local/root "/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-2.12.13.1.jar", :deps/manifest :jar, :deps/root "/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-2.12.13.1.jar", :parents #{[]}, :paths ["/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-2.12.13.1.jar"]}

This error message helps identify which dep (and in this case, which exact jar file) is causing the problem, but I don't know if there is any information in there that could help identify the cause problem. Am I missing the way to interpret this exception? Are there any common causes of this?