Hi guys, does anyone have a cljs tools-deps library I can look at? Trying my hand at it, but somehow the library can’t see itself. Lol

I'm interested in solving TDEPS-12, @alexmiller have you thought about how you'd like it to be done?

how to use clj cli compile java code

I have some java code in classpath

@dominicm I don’t think anything on that ticket is very good thinking about this problem

the problem is that the assumption going into the design is that there is a 1-1 correspondence between library name and artifact

this is a case where that is not true

everything else flows from that and without addressing that fundamental issue, there is no way to fix the issue

I’ve been thinking about this for a long time and I think you have to solve the “name” part or you’re not fixing anything

the library name here is used for dual purposes - identification in tools.deps, and lookup in Maven (the groupId:artifactId). In many places we key maps based on #1 so that really needs a new dimension of context that is more than just #2.

that means encoding the classifier into the name (so you get uniqueness of identity) and have the Maven extension know how to decode that for lookup

that could be done with a name encoding, or by using something other than a symbol as the library name

Interesting. When discussing with @malcolmsparks I dismissed the notion of using a vector or some encoding for the key. Something not mentioned is that there's more than just classifier as a dimension in Maven, there's also type. I suspect encoding is a bad solution because it's not information dense enough.

would be an example idea for a symbol encoding

Sure. But then you have type too.

type is not important

tools.deps is about classpaths

it is not about “providing a generic interface to all things Maven”

the only type we care about is jars

Are we certain type isn't important? If so I agree that the symbol is the only important one. It would be a shame to use encoding, and then end up having to cram something additional in.

give me an example where type is important

(I’ve done this exercise and not come up with anything)

another option is to support an expanded lib name like {:groupId "group.id", :artifactId "artifactId", :classifier "classifier"}

doing one does not preclude doing the other later

I don't have one to hand, that's certain. In that case I will defer to your data. My objection was weak and I was erring on the side of exposing everything in the case of not having access to any data.

tools.deps has been out for about a year and I haven’t seen a request or question about anything other than classifiers

If we did that, would it be a consistent return value? I'm guessing it would involve changing the current lib map spec?

what is “it” in above?

The map version of the lib name.

yes, would change (grow) the spec and a couple things in the Maven extension canonicalization

I really need to talk to Rich to make a decision on that

At the moment I rely on it being a symbol in pack, in order to perform naming. That seems like a breaking change for me. Am I relying on a property I shouldn't?

the code changes are pretty trivial. thinking clearly about the problem here is the important part.

> choose whatever name you want with lowercase letters and no strange symbols. I was just looking into which character was appropriate. Maven is surprisingly coy about what is allowed...

I guess I will just have to test.

lol so I blew out ~/.m2 and now when I try and run clj:

Error: Could not find or load main class clojure.main

@lilactown I'm guessing because the classpath is cached

yes, if you manually muck with .m2, you’ll need to use clj -Sforce

currently clj does not do any checks to verify that all the dirs/files on the classpath exist

I’m a bit on the fence about it - that could be added, but has the downside of a) adding startup time and b) not being tolerant of (for example), a missing src path on the cp. although I guess you could maybe only check the files.

Maybe just a warning to “if in doubt, clj -Sforce” on “missing” errors?

yeah, I didn’t know about -Sforce. that would be a helpful enhancement

Or, could do the path checking AFTER the error occurs, in which chase “start up time” isn’t a factor.

Verify that there are missing paths for a good error message, not re-do the whole op.

the benefit of doing it before is that you can potentially fix it, not error

if stuff is stale, then force

the question I’d like to answer is - how long does it take to do the check for a reasonable size classpath

Right. The “after” idea is to keep the speed benefits, but provide a clearer option for the user to try: same as it is now, just slightly clearer.