https://clojure.atlassian.net/browse/TDEPS-184

Hah! It was even my "ask" -- for exactly this situation we have at work, which has just gotten more complex since I asked for that feature!

realistically, I'm unlikely to have time to work on it soon, so depending on your desire for urgency, patches welcome :)

even if starting a patch uncovered questions, that would be helpful

OK, I might take a run at that since it sounds like it would be accepted/appreciated.

I'm not opposed to it, just not sure where the dragons lie (maybe none!)

Since I'm not a Maven user, any idea about this:

(~/oss/tools.deps.alpha)-(!2022)-> mvn -version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 19, vendor: Eclipse Adoptium, runtime: /Developer/jdk-19+36
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.68.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Fri Nov 18 12:05:55
(~/oss/tools.deps.alpha)-(!2023)-> mvn test
[ERROR] Error executing Maven.
[ERROR] java.lang.IllegalStateException: Unable to load cache item
[ERROR] Caused by: Unable to load cache item
[ERROR] Caused by: Could not initialize class com.google.inject.internal.cglib.core.$MethodWrapper
[ERROR] Caused by: Exception com.google.inject.internal.cglib.core.$CodeGenerationException: java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @2bbaf4f0 [in thread "main"]

Do I just need to use an older JDK to run it?

well the ClassFormatError and the "module" suggest to me that there is something either class version or module related

-e will print more of the error

and -X is debug mode

oh, you're trying to run the tools.deps build itself, didn't realize that

I don't currently run have anything newer than Java 17, and it runs with that

I'm using this now and mvn test works for me:

% mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 19, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk/19/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.6.1", arch: "x86_64", family: "mac"

maybe mvn clean test to make sure you don't have anything old in target?

Ah, 3.6.3 is what's installed by apt on Ubuntu for me. It runs on JDK8 just fine. I ought to rebuild my dev env on a more recent Ubuntu at some point 🙂 Thanks for the sanity check.

So, for TDEPS-184, how do you feel about expanding it to support :main-opts as well? (I have it all working for :jvm-opts already with some fun tests)

It would be almost trivial at this point to support aliases in :main-opts with the code I've added for :jvm-opts -- and it might be useful to folks...

hold off on that for now, it plays into other ideas I have

semantics are different too due to replacement rather than unioning

That's why I asked 🙂 But it would now be as simple as changing this:

;; handle jvm and main opts
        jvm (seq (flatten-opts :jvm-opts exec-argmap merge-edn))
        main (seq (get exec-argmap :main-opts))]

;; handle jvm and main opts
        jvm (seq (flatten-opts :jvm-opts exec-argmap merge-edn))
        main (seq (flatten-opts :main-opts exec-argmap merge-edn))]

The addition to make_classpath2.clj is this (a variant of how paths are handled in alpha.clj):

(defn- chase-opts-key
  "Given an aliases set and a keyword k, return a flattened vector of
  options for that k, resolving recursively if needed, or nil."
  [aliases k]
  (let [opts-coll (get aliases k)]
    (when (seq opts-coll)
      (into [] (mapcat #(if (string? %) [%] (chase-opts-key aliases %))) opts-coll))))

(defn- flatten-opts
  [opt-key exec-argmap {:keys [aliases] :as merge-edn}]
  (let [aliases' (assoc aliases opt-key (get exec-argmap opt-key))]
    (into [] (remove nil?) (chase-opts-key aliases' opt-key))))

just drop me a patch and I'll take a look

With both or just JVM opts?

I'll do both since it's now so easy. And you can decide what to do with it.

I will add some :main-opts tests for this case as well tho'...

with just jvm-opts, don't want the main-opts right now

Got it!

Patch attached to the ticket (created from the GH PR against my own repo -- so I hope the format is acceptable).

Sure, I can add that

I did add a deps.edn at one point: https://github.com/clojure/tools.namespace/blob/master/deps.edn but it doesn't seem to pull in the deps from the pom.xml

when used as a git dep

interesting, I see that

When I run it out of a tools.deps repl it works, so something weird there

out of a tools deps repl?

I would be fine with just replicating the pom.xml paths and deps in deps.edn though, the trick I used there is admittedly a bit hacky

I take it back, it is working for me, I flubbed the cli

do you have a repro of this not working?

% clj -Stree -Sdeps '{:deps {io.github.clojure/tools.namespace {:git/sha "bd78b34d9551c99910a24ce939c2137fcf1bede1"}}}'
org.clojure/clojure 1.11.1
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
io.github.clojure/tools.namespace bd78b34
  . org.clojure/tools.namespace /Users/alex.miller/.gitlibs/libs/io.github.clojure/tools.namespace/bd78b34d9551c99910a24ce939c2137fcf1bede1
    . org.clojure/java.classpath 1.0.0
    . org.clojure/tools.reader 1.3.6

@alexmiller My situation is like:

clj -Stree -Sdeps '{:deps {org.clojure/tools.namespace {:git/url "" :git/sha "bd78b34d9551c99910a24ce939c2137fcf1bede1"}}}'

org.clojure/clojure 1.11.0
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
org.clojure/tools.namespace bd78b34
  X org.clojure/tools.namespace /Users/borkdude/.gitlibs/libs/org.clojure/tools.namespace/bd78b34d9551c99910a24ce939c2137fcf1bede1 :use-top

but maybe this prevents including the pom.xml self-reference

oh, yeah that won't work as is due to the same name

in this case, probably easiest to just double-maintain the libs

agreed

pushed

e08261e4b522e45916bdff24a1ac99b478676f12

Thanks! Does it also need "src/main/clojure" in :paths?

I think it does

but I can add that manually in my tests to the classpath, so no hurry

It doesn’t, as that is always in the deps list via the root

That's only src right?

No

$ clj -Sdeps '{:deps {io.github.clojure/tools.namespace {:git/sha "e08261e4b522e45916bdff24a1ac99b478676f12"}}}'
Clojure 1.11.0
user=> (require '[clojure.tools.namespace])
Execution error (FileNotFoundException) at user/eval1 (REPL:1).
Could not locate clojure/tools/namespace__init.class, clojure/tools/namespace.clj or clojure/tools/namespace.cljc on classpath.

I also don't see src/main/clojure in the classpath

$ clj -Spath -Sdeps '{:deps {io.github.clojure/tools.namespace {:git/sha "e08261e4b522e45916bdff24a1ac99b478676f12"}}}'
src:/Users/borkdude/.gitlibs/libs/io.github.clojure/tools.namespace/e08261e4b522e45916bdff24a1ac99b478676f12/src:/Users/borkdude/.m2/repository/org/clojure/clojure/1.11.0/clojure-1.11.0.jar:/Users/borkdude/.m2/repository/org/clojure/java.classpath/1.0.0/java.classpath-1.0.0.jar:/Users/borkdude/.m2/repository/org/clojure/tools.reader/1.3.6/tools.reader-1.3.6.jar:/Users/borkdude/.m2/repository/org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar:/Users/borkdude/.m2/repository/org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar

oh, should be src/main/clojure

but notice clojure is there

daf82a10e70182aea4c0716a48f3922163441b32

works, thanks a lot!

root deps.edn is: https://github.com/clojure/tools.deps.alpha/blob/master/src/main/resources/clojure/tools/deps/deps.edn

it has a :deps that includes clojure by default (and this is why you can just run clojure in any directory and start clojure.main repl

yes, I get that, but I've never seen src/main/clojure (not just src) be added to the classpath automatically, which was what I was getting at

thanks for the fix

ah, then yes. we actually used to do that in the early days

but I decided that was 2x more special things than we needed :)

I'm using git deps to also pull tests to disk which I'm then running with babashka. Currently I'm making it (bb) work with tools.namespace which then makes it work with the cognitect test runner as is

nice

I guess we could have just used a dummy name in that deps.edn local/root, which was not the name of the lib itself, then it would also have worked

but then that name would appear in the deps tree which would be a bit odd

Yes that would have worked too