Clojurians Log v2
depstar
@seancorfield So where do you think this PR is best implemented? https://github.com/slipset/deps-deploy/issues/20 My feeling was it was better pushed upstream into either depstars library building phase or a separate pom-update tool. I’m guessing you’d rather the later.
It belongs more with depstar than at deployment because the POM etc inside the JAR needs it. I'll point out that if you use -X with depstar you get t.d.a inside your JAR, which is probably not what you want.
Why would I get t.d.a inside the JAR when calling with -X?
I’m pretty sure the t.d.a lib itself isn’t included on the running JVMs classpath unless you include it explicitly as a dependency, because the CLI tools do a JVM trampoline after the resolve/make/cache classpath phases.
Confirmed with:
(ns foo.bar)
(defn class-path [_]
(println (System/getProperty "java.class.path")))clojure -Sdeps '{:paths ["src"]}' -X foo.bar/class-path
src:/Users/rick/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/Users/rick/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar:/Users/rick/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/usr/local/Cellar/clojure/1.10.1.716/libexec/exec.jarAlex has fixed that part then. But you do get clojure/1.10.1.716/libexec/exec.jar on your classpath.
Yeah, though that has no transitive dependencies other than clojure at least 🙂
And I’m guessing it’s guaranteed that it won’t ever have any transitive deps
Dunno. As far as I'm aware, it's undocumented and "just an implementation artifact".
(I suspect it may become part of Clojure "core" in 1.11 the way things are going)
It is; but it was presumably added to prevent the classpath being polluted by t.d.a deps; which are likely to change over time etc
Changing the version alone in a POM is also probably not what you want since tooling also relies on the SCM tag.
It’s pretty easy to include overriding the SCM tag too
This is not a simple problem to solve correctly.
I would also say that the "correct" approach here would be to have some sort of templating system that allows users to have stuff like ${version} in pom.xml and have depstar make substitutions, based on command-line arguments. But depstar made a very deliberate choice to have no dependencies, and to work (by default) from exactly the supplied classpath. Which means that whatever command-line arguments are for this, depstar would have to continue to parse them itself (rather than relying on tools.cli, for example, as clj-new does (because it already has a load of dependencies). And while the -X approach with depstar would allow for that easily, you'd then get t.d.a in your (uber) JAR file which might be problematic.
All of this has to be taken into account -- and, frankly, I'd rather wait and see what tools.build does because I'm pretty sure this is a solved problem in tools.build, based on some of the workflows Alex has talked about.
Again I only think this needs to be taken into account because of uberjars. If we were to hypothetically make depstar only about uberjars and make a new library only about jars, uberjarring concerns wouldn’t be driving library making concerns.
Fair enough. I'll give it some thought. But, still, I'm not going to expend too much effort with tools.build on the horizon.