Fork me on GitHub

@samwagg0583 author of lein-tools-deps here. It does let you do what @seancorfield says; though I wouldn’t recommend ltd for projects that have complex transitive downstream dependencies. The reasoning is covered in the README here: However there is an open issue to fix this, and a known solution for fixing it: (As an aside I’m unlikely to find the time to fix this myself anytime soon; but am open to PRs). I think this is the most important issue to fix in that project.


@U06HHF230 Thanks for the info!


For the moment, I went the route of publishing a pom.xml in the target repo. But I may explore your lib more in the future.

Jakub Holý (HolyJak)14:01:52

Hello! Does anyone have an example how to create a simple clojure + java based project with deps.edn? (Clojure will use some Java classes). Quick googling revealed nothing relevant...

👍 4
Alex Miller (Clojure team)14:01:23

deps does not explicitly support Java compilation

Alex Miller (Clojure team)14:01:03

so you either need something that can combine deps with javac, or split the project into java part and clojure part


@holyjak if you haven't checked out @mike1452's recent 2 announcements for the clj-new templates slib and sapp, may be it's worth a look?

Alex Miller (Clojure team)16:01:08

moving here from announcements sub-thread. @seancorfield I'm seeing an error trying to use clj-new with that sapp template:

Alex Miller (Clojure team)16:01:12

clj -A:new  qwerty/asd
Failed with: org.apache.maven.repository.internal.DefaultModelResolver.<init>(org.eclipse.aether.RepositorySystemSession,org.eclipse.aether.RequestTrace,java.lang.String,org.eclipse.aether.impl.ArtifactResolver,org.eclipse.aether.impl.VersionRangeResolver,org.eclipse.aether.impl.RemoteRepositoryManager,java.util.List)
Execution error (ExceptionInfo) at clj-new.helpers/resolve-remote-template (helpers.clj:149).
Could not load artifact for template: slib
	Tried coordinates:
		[slib/boot-template "RELEASE"]
		[slib/lein-template "RELEASE"]
Full report at:

Alex Miller (Clojure team)16:01:13

The DefaultModelResolver thing is either the problem I just fixed in latest tools.deps.alpha or a version conflict due to pomegranate (both kind of looked similar errors). I notice that clj-new is using a pretty old version of tools.deps?


hmm, interesting. i just checked out template on clear centos 7 with latest clj-new 0.8.5 and tools deps. everything works fine. can't reproduce DefaultModelResolver error.

Alex Miller (Clojure team)16:01:35

My clj-new alias is

:new {:extra-deps {seancorfield/clj-new {:mvn/version "0.8.5"}}
              :main-opts ["-m" "clj-new.create"]}


so, my alias looks the same: :new {:extra-deps {seancorfield/clj-new {:mvn/version "0.8.5"}} :main-opts ["-m" "clj-new.create"]}

Alex Miller (Clojure team)16:01:17

if it's the conflict with transitive pomegranate maven deps, that may be the kind of thing that is arbitrary and resolves differently on different machines. can you dump me clj -Stree -A:new ?

Alex Miller (Clojure team)16:01:02

and also, what version of clj are you on (`clj -Sdescribe`)


mike@mbp02:~$ clj -Stree -A:new
org.clojure/clojure 1.10.1
  org.clojure/core.specs.alpha 0.2.44
  org.clojure/spec.alpha 0.2.176
seancorfield/clj-new 0.8.5
  com.fasterxml.jackson.core/jackson-databind 2.7.5
    com.fasterxml.jackson.core/jackson-annotations 2.7.0
  org.clojure/tools.cli 0.4.2
  com.fasterxml.jackson.dataformat/jackson-dataformat-cbor 2.7.5
  com.fasterxml.jackson.core/jackson-core 2.7.5
  org.clojure/tools.deps.alpha 0.7.541 5.0.0.RELEASE
    org.apache.maven.resolver/maven-resolver-transport-wagon 1.1.1
    org.apache.maven.resolver/maven-resolver-transport-http 1.1.1
      org.slf4j/jcl-over-slf4j 1.7.25
      org.apache.httpcomponents/httpcore 4.4.8
      org.apache.httpcomponents/httpclient 4.5.4
        commons-codec/commons-codec 1.10
    org.apache.maven.resolver/maven-resolver-transport-file 1.1.1
    org.apache.maven/maven-core 3.5.2
      javax.inject/javax.inject 1
      org.codehaus.plexus/plexus-component-annotations 1.7.1
      org.apache.commons/commons-lang3 3.5
      org.codehaus.plexus/plexus-utils 3.1.0
      org.eclipse.sisu/org.eclipse.sisu.plexus 0.3.3
        javax.enterprise/cdi-api 1.0
          javax.annotation/jsr250-api 1.0
      org.apache.maven/maven-settings-builder 3.5.2
        org.sonatype.plexus/plexus-sec-dispatcher 1.4
          org.sonatype.plexus/plexus-cipher 1.4
        org.codehaus.plexus/plexus-interpolation 1.24
      org.apache.maven/maven-settings 3.5.2
      org.apache.maven.shared/maven-shared-utils 3.1.0
        commons-io/commons-io 2.5 20.0
      org.codehaus.plexus/plexus-classworlds 2.5.2$no_aop 4.0
        aopalliance/aopalliance 1.0
      org.eclipse.sisu/org.eclipse.sisu.inject 0.3.3
      org.apache.maven/maven-plugin-api 3.5.2
    org.apache.maven.resolver/maven-resolver-api 1.1.1
    org.clojure/data.xml 0.2.0-alpha5
      org.clojure/data.codec 0.1.0
    org.apache.maven.resolver/maven-resolver-spi 1.1.1
    s3-wagon-private/s3-wagon-private 1.3.1
      com.amazonaws/aws-java-sdk-s3 1.11.184
        com.amazonaws/jmespath-java 1.11.184
        com.amazonaws/aws-java-sdk-core 1.11.184
          joda-time/joda-time 2.8.1
          commons-logging/commons-logging 1.1.3
        com.amazonaws/aws-java-sdk-kms 1.11.184
    org.clojure/tools.gitlibs 0.2.64
      com.jcraft/jsch.agentproxy.jsch 0.0.9
        com.googlecode.javaewah/JavaEWAH 1.1.6
        com.jcraft/jsch 0.1.54
      com.jcraft/jsch.agentproxy.connector-factory 0.0.9
        com.jcraft/jsch.agentproxy.sshagent 0.0.9
        com.jcraft/jsch.agentproxy.usocket-jna 0.0.9
        com.jcraft/jsch.agentproxy.pageant 0.0.9
        com.jcraft/jsch.agentproxy.core 0.0.9
        com.jcraft/jsch.agentproxy.usocket-nc 0.0.9
    org.apache.maven.resolver/maven-resolver-connector-basic 1.1.1
    org.apache.maven.resolver/maven-resolver-impl 1.1.1
    org.apache.maven.resolver/maven-resolver-util 1.1.1
  org.slf4j/slf4j-nop 1.7.25
    org.slf4j/slf4j-api 1.7.25
  com.cemerick/pomegranate 1.1.0
    org.apache.maven.wagon/wagon-provider-api 3.0.0
    org.apache.maven/maven-resolver-provider 3.5.3
      org.apache.maven/maven-model-builder 3.5.3
        org.apache.maven/maven-builder-support 3.5.3
        org.apache.maven/maven-artifact 3.5.3
      org.apache.maven/maven-model 3.5.3
      org.apache.maven/maven-repository-metadata 3.5.3
    org.apache.maven.wagon/wagon-http 3.0.0
      org.apache.maven.wagon/wagon-http-shared 3.0.0
        org.jsoup/jsoup 1.7.2
    org.tcrawley/dynapath 1.0.0
  stencil/stencil 0.5.0
    quoin/quoin 0.1.2
    scout/scout 0.1.0
    org.clojure/core.cache 0.6.3
      org.clojure/data.priority-map 0.0.2
  com.fasterxml.jackson.dataformat/jackson-dataformat-smile 2.7.5

Alex Miller (Clojure team)16:01:27

bumping to latest tools.deps with clj-new worked

Alex Miller (Clojure team)16:01:30

:new {:deps {seancorfield/clj-new {:mvn/version "0.8.5"}
                    org.clojure/tools.deps.alpha {:mvn/version "0.8.640"}}
              :main-opts ["-m" "clj-new.create"]}

Alex Miller (Clojure team)16:01:14

probably because I'm not calling the DefaultModelResolver at all in latest

Alex Miller (Clojure team)16:01:34

I guess @seancorfield that I would suggest maybe bumping tda in clj-new


I will add org.clojure/tools.deps.alpha {:mvn/version "0.8.640"} as recommendation to README in case of errors

Alex Miller (Clojure team)16:01:33

well, I'd hold off on that, I hate to cargo cult workarounds like that

Alex Miller (Clojure team)16:01:52

I work with a hacked up clj environment a lot of the time and this may truly be just something on my machine (although I think I have undone all of that)


@alexmiller Can you open an issue on clj-new to bump the deps? That way I won't forget when I get to work, and I'll cut 0.8.6 today.


@mike1452 seancorfield/clj-new {:mvn/version "0.8.6"} is up on Clojars -- can you try that out (without adding t.d.a.) and see if it resolves your issues?


I also bumped Pomegranate to the latest version, which is on clj-commons now, which may (or may not) cause new problems since the group ID has changed and code will possibly get two versions of it...


(the Jackson dependency hell conflicts with various templates are why 2.7.5 of that is also pinned in clj-new since Luminus' template was breaking before -- due to it relying on Leiningen's version resolution avoiding a conflict there)

Alex Miller (Clojure team)17:01:45

btw, as of the new s3 transporter in tda, it no longer has a jackson dep


OK, I may remove that and see if Luminus or other project templates still break.

Alex Miller (Clojure team)17:01:51

you may still be pulling it in from multiple places, but tda is not one of them :)


Luminus templates seem to generate OK without clj-new's deps on Jackson so in 0.8.7 I'll take them out.

Alex Miller (Clojure team)17:01:13

also, you probably want the clj-new alias to be :deps, not :extra-deps so that you override, instead of add to, the deps of the current project deps.edn if there is one


Good point. That wasn't available before.

Alex Miller (Clojure team)17:01:40

usually it probably doesn't matter as you're making a new project

Alex Miller (Clojure team)17:01:59

(but note that this requires a sufficiently new clj version, and you'll get an error if using older)

Alex Miller (Clojure team)17:01:59

I'd recommend at least clj (Nov 2019 vintage)

Alex Miller (Clojure team)17:01:14

so maybe that's something to hold off on


Yeah... I'll give it a month or two and a few more releases of clj before I make that change. I just saw someone still using clj-new 0.5.5 😐


@seancorfield I'll check. just a moment.


I have a tools-deps based project with a Clojure backend (lacinia-pedestal) und a re-frame frontend (ClojureScript). So it is a mixed Clojure/ClojureScript project. I’m using :aliases to run the server and the frontend (via shadow-cljs). Am I supposed to define the deps as :extra-deps in the related aliases? I just debugged an issue where jetty stopped working with very strange exceptions and that was related to having pedestal-lacinia and re-graph in :deps which caused incompatible versions of jetty libraries loaded. Moving the re-graph dep into the frontend alias solved the problem.

Alex Miller (Clojure team)17:01:58

if you have deps that are only needed when the alias is enabled, then they should be :extra-deps in that alias

👍 4
Alex Miller (Clojure team)17:01:07

sorry if I misinterpreted the question


I guess that’s the answer, since it is working. Is it in general a good/bad idea to have client and server in one deps.edn?

Alex Miller (Clojure team)17:01:35

I don't think it's either good or bad


True neutral?

Alex Miller (Clojure team)18:01:44

or maybe lawful neutral

😄 4

At least it is very convenient when working with cursive inde IntelliJ IDEA. Guess I really have to give emacs a try one day…


Fwiw, I find it equally useful with vim, and my colleagues do with emacs.


I try to defer splitting projects as long as possible. Development is faster when you don't have to fabricate arbitrary boundaries between things where you haven't found the boundary yet


While I agree with this sentiment in general, dealing with dependencies will cause troubles sooner or later (not only in clojure / java, but development in general). If I have learned something over the decades it's these rules. 1. Uses as few dependencies as possible. 2. Separate these as much as possible. 3. Use the same version of a dependency everywhere, if you can. 4. Avoid gradle and eclipse, as eclipse still cannot separate classpathes like gradle does.


Tools deps has made my life significantly better in this space, so has the clojure culture of not breaking the api

parrot 4

@seancorfield @alexmiller I have updated templates on GitHub with clj-new 0.8.6+