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 java.lang.Object@5ddf0d24>

Changed in 1.7

Clojure 1.2.1
#<Object java.lang.Object@38d8f54a>
Clojure 1.3.0
#<Object java.lang.Object@692f203f>
Clojure 1.4.0
#<Object java.lang.Object@3d34d211>
Clojure 1.5.1
#<Object java.lang.Object@117e949d>
Clojure 1.6.0
#<Object java.lang.Object@6ff29830>
Clojure 1.7.0
#object[java.lang.Object 0x2cdd0d4b "java.lang.Object@2cdd0d4b"]
Clojure 1.8.0
#object[java.lang.Object 0x702b8b12 "java.lang.Object@702b8b12"]
Clojure 1.9.0
#object[java.lang.Object 0x13df2a8c "java.lang.Object@13df2a8c"]

(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: https://clojure.org/guides/deps_and_cli#_using_local_libraries and sometimes we get the dreaded Manifest type not detected error...it is a local dep with a deps.edn and I wonder how I can debug what is going wrong...

probably related to relative paths if I had to guess

is it a transitive local dep?

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 ^

https://dev.clojure.org/jira/browse/TDEPS-74

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

@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

true

tools.deps is hardcoded to look only for jar extension

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.

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

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)

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

which is in some ways deeply weird

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

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

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

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

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?

sorry

I’ve merged with the borg apparently

Group Artifact Version (standard Maven ID)

groupId/artifactId/version

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?

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

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

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.

intellij does this already

that is, download and use source and javadoc for libs