Fork me on GitHub

I could have sworn I've seen the #<some-object> notation before


$ clojure -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.2.1"}}}' -e '(Object.)'
#<Object [email protected]>


Changed in 1.7

Clojure 1.2.1
#<Object [email protected]>
Clojure 1.3.0
#<Object [email protected]>
Clojure 1.4.0
#<Object [email protected]>
Clojure 1.5.1
#<Object [email protected]>
Clojure 1.6.0
#<Object [email protected]>
Clojure 1.7.0
#object[java.lang.Object 0x2cdd0d4b "[email protected]"]
Clojure 1.8.0
#object[java.lang.Object 0x702b8b12 "[email protected]"]
Clojure 1.9.0
#object[java.lang.Object 0x13df2a8c "[email protected]"]


(the new CLI stuff makes this so easy to test!)


for clojure in 1.2.1 1.3.0 1.4.0 ...


We have a monorepo with this exact setup: and sometimes we get the dreaded Manifest type not detected is a local dep with a deps.edn and I wonder how I can debug what is going wrong...

Alex Miller (Clojure team)03:09:05

probably related to relative paths if I had to guess

Alex Miller (Clojure team)03:09:17

is it a transitive local dep?

Alex Miller (Clojure team)03:09:53

there is a known issue that transitive local deps resolve paths in terms of your current directory, not in terms of the dep, which can lead to issues with finding the correct “dep root” (where the deps.edn would be expected)


@alexmiller yes it is a transitive dep that of one of the sub projects and one colleague has noticed that if he specifies it top level the problem goes away.


Thanks then good to know the problem is known I will check Jira


@cfleming thanks this is the reason of the Cursive message ^

Alex Miller (Clojure team)03:09:42

that’s the placeholder for it, there might be another one that’s same thing

👍 4

@richiardiandrea Thanks for letting me know.


@alexmiller someone in #leiningen just discovered that openjfx uses <type>pom</type> which wouldn't be supported by deps.edn


just as a data point

Alex Miller (Clojure team)17:09:38

tools.deps is hardcoded to look only for jar extension

Alex Miller (Clojure team)17:09:56

the original example in TDEPS-12 is all jars


Yep. This was something @malcolmsparks pointed out a little later. Pom is something that is logically consistent with classpath building. I don't know how type interacts with classifier, I suspect it's multiplicative.


Not quite. Each classifier/type combination is specified in a separate dependency element in the POM.


@alexmiller thanks for comment in TDEPS-12, I've been able to build a local version of tools.deps and patch it into my /usr/bin/clojure script, no problem. Still testing.


It might be that a classifier key is wrong, and it should be named otherwise, and be maps with classifier and type in.

Alex Miller (Clojure team)17:09:03

usually I just add the source directory of tools.deps.alpha to the front of the lib path in my clojure script :)

Alex Miller (Clojure team)17:09:45

poms are used for determining transitive deps but are not themselves artifacts that get put on the classpath (these are independent parts of the tools.deps extension spi)

Alex Miller (Clojure team)17:09:00

all classifiers in a group/artifact/version share the same pom

Alex Miller (Clojure team)17:09:15

which is in some ways deeply weird

Alex Miller (Clojure team)17:09:43

and really reinforces that GAV should primarily be about “one” artifact

Alex Miller (Clojure team)17:09:36

I think you could argue pretty readily that the case in TDEPS-12 for example should be different artifactIds, not classifiers, but I don’t run the world :)


I was thinking the same. But I did realize that having structure provides the opportunity for tooling to inspect it. Eg automatically fetching src & javadoc classifiers. In the TDEPS-12 case, tooling has less of a place, but could feasibly be done by a maven plugin

Alex Miller (Clojure team)18:09:29

source and javadoc are secondary info (just like Clojure meta) and make total sense to me

Alex Miller (Clojure team)18:09:33

even things like aot as a secondary classifier make sense to me as a variant of the same artifact

Alex Miller (Clojure team)18:09:17

any case where you’re putting more than one artifact from the same GAV on your classpath at the same time seems … weird


I don't know GAV. Google isn't too revealing either, what is it?

Alex Miller (Clojure team)18:09:09

I’ve merged with the borg apparently


Group Artifact Version (standard Maven ID)

Alex Miller (Clojure team)18:09:40


Alex Miller (Clojure team)18:09:55

nice slack, out of order message delivery


My guess was surprisingly accurate. The version part didn't quite fit for me.


Just so I'm clear, do you think javadoc should be a separate GAV with a pointer from the root? Or that context does make sense for a classifier?

Alex Miller (Clojure team)18:09:18

no, I think the existing usage of classifiers for javadoc and source make sense

Alex Miller (Clojure team)18:09:33

I think cases like the one in TDEPS-12 are weird

Alex Miller (Clojure team)18:09:50

all those classifiers should be separate artifacts


I wonder how hard it would be to have a tool which synchronized your Maven deps to add a profile with javadoc and source. I'd love that for stack traces. A bit of a shame that it would be duplicative to isolate to an alias with the current classifier data shape. Not terrible I suppose though.


I suppose you could use such a tool through -Sdeps too, but then cider would have to become aware of it... Unless it was a dependency of cider, then everyone would have it and be happy forever!


Not everyone uses CIDER tho'...


(heresy, I know!)


I think intellij is the only editor that doesn't. And atom.


Intellij probably already does this, so is less interesting. Atom would miss out, but could integrate directly with the library.

Alex Miller (Clojure team)22:09:36

intellij does this already

Alex Miller (Clojure team)22:09:02

that is, download and use source and javadoc for libs