Fork me on GitHub
Alex Miller (Clojure team)02:06:27

@jmv305 yes, set the :mvn/local-repo attribute at the root of deps.edn (or in -Sdeps on command line) - takes a string that is a path to the root


thank you alex, that worked!

Alex Miller (Clojure team)02:06:02

clj -Sdeps '{:mvn/local-repo "/right/here"}'


I’m getting an error when I put clojure 1.10.1 in my extra-deps. I wanted the dependency to be there in my maven repo during test time, since I’m analyzing the source code.

;; org.clojure/clojure {:mvn/version "1.10.1"}


The error being:

Running tests in #{"test"}
Syntax error (ClassNotFoundException) compiling at (clj_kondo/core_test.clj:1:1).


I didn’t want to declare that clojure version at my top level, since I don’t want to force that version on other people


trying a repro


I can force the download in another way, never mind

Jakub Holý (HolyJak)09:06:58

Does anyone know how to publish a deps.edn-based library to Clojars? Its docs do not mention it


I'm using maven for that. clj -Spom and then mvn deploy.


Yup that's how I do it too. With depstar to create the JAR.


The pom generated by clj is minimal -- you'll need to add a bunch of stuff and edit things. See the pom.xml file in the depstar repo. Without all the extra stuff Clojars won't know how to refer back to your source repo and you won't be able to import your library on either.


next.jdbc is also published this way.


this is good to know. I currently still mirror my deps in a project.clj and then call lein deploy


do you update the version in the pom by hand?


good question. I wonder where the version comes from since that’s not present in deps.edn?


Yes, I update the pom.xml <version> tag manually. But the the SCM <tag> is updated by my deploy shell script when I make a release.


So my process the first time is clj -Spom and add all the SCM stuff etc into the skeletal pom.xml (by copying from another project and editing all the URLs etc).


Subsequent times: do the edits to prepare for the release, push to GH, create a new release on GH with release notes, pull (to ensure I have the latest master locally), then clj -Spom && clj -A:jar project.jar && git status (to verify the pom.xml didn’t change again). Then I usually re-run the test suite at this point. Then deploy project, which updates the pom.xml from the HEAD SHA, commits & pushes it, then uses mvn deploy to push it up to


This is how I update the pom.xml in my deploy script

sha=`git rev-parse HEAD`
version=`fgrep '<version>' pom.xml | head -1 | sed 's;.*<version>\(.*\)</version>.*;\1;'`
echo "Setting tag to ${sha} for version ${version}..."
cp pom.xml /tmp/${1}.pom.xml
sed "s;<tag>[0-9a-f]*</tag>;<tag>${sha}</tag>;" < /tmp/${1}.pom.xml > pom.xml


This is the deploy line:

mvn deploy:deploy-file -Dfile=${1}.jar -DpomFile=pom.xml -DrepositoryId=clojars -Durl=


thanks sean, this is helpful to see


The automated commit looks like this but the actual release — whatever was tagged by GH — is what Clojars points to, e.g., (which is one before that).


However, it’s the <tag> in the pom.xml that drives when it fetches the project from GH to analyze — and that means it gets the deployed version (which is one commit ahead of the release). Just something to bear in mind.


right that makes sense