Clojurians Log v2
tools-build 2021-09-23
In the tools.build example here: https://clojure.org/guides/tools_build#_compiled_uberjar_application_build Why write a pom to an uberjar??
Infact I really don’t understand that example… Is that building a library or application?! In my experience they’re typically very different types of build.
> Compiled uberjar application build > > When preparing an application, [...] There's another section right above the one you linked to that describes how to create a jar for a library. Seems pretty clear to me, unless you're referring to something else?
Yes I see the two titles…
What I’m asking is why an application / uberjar would typically require a pom.xml to be put inside it.
given that you never put applications in clojars or maven central — or depend on them like libraries.
You don't have to
You still might put it in a local or company repo where metadata is useful
maybe — I’m not saying you’d never want to do this; just that it seems like an odd example for building an application.
Well, I could remove that part if it's confusing
I think it might help… It’ll make it clearer that the pom isn’t actually necessary for an uberjar.
It's not necessary for any classpath - we should maybe be filtering this in tools.deps
is that comment meant for this thread or the main thread?
here - .pom files have no meaning in a classpath
oh sorry, maybe not here
too many threads!
yeah sorry
Also thanks again for everything 🙇
I’ve been enjoying trying to port some things over to tools.build
In my build-clj wrapper, you can omit :version and then uber skips the pom-writing.
Yes, you sometimes see libraries that are also wrapped into a CLI app or something — but it seems to me in those projects you’re still doing two very different two things; deploying a library for API consumers and building an application.
@rickmoynihan For me, pom.xml is useful in two scenarios: 1. Inspect artifact on CI to control deps licenses. We want to avoid use of incompatible licenses. 2. In closed environment (without Internet) we have to use maven + pom.xml to download dependencies from corporate Nexus before build. This is because in tools deps we cannot use custom settings.xml. On our CI servers ~/.m2/settings.xml is always empty and we should use custom settings.xml for every project to set corporate Nexus. Depstar (now archived) help us to solve this issue.
I can see the first might be useful for audit in some very specific scenarios — but you could just as easily do it before you generated the build. The second point isn’t really relevant to what I’m asking. i.e. I understand the role of maven in acquiring dependencies so you can make your build. What I don’t understand is why the guide is suggesting you put the pom.xml into the application. It seems to me that the example is bluring the distinction between building and deploying a library; and building an application/uberjar. It’s not uncommon to see this distinction blurred. For example depstar which you referenced complected both concerns together trying to be a tool for both uberjarring applications and jarring libraries. Yes there are some commonalities; but IMHO most of the complexity in depstar was due to needing to isolate classpaths for the uberjar application case; which meant it couldn’t acquire new features and in particular 3rd party deps — which would have helped improve the situation for creating libraries e.g. updating versions in poms etc…
That was only true in 1.0. In 2.0 the classpath was built separately and depstar had whatever deps it needed.
Another tools.build question…
When would you want to b/compile-clj with :sort :bfs instead of :sort :topo?
I don't know if you'd ever want it but I left it as an option
I guess it might be quicker if it’s already built stuff, as it’s checking from the top down?!
That's topo - bfs is basically doing the compilation in lexica sort order
Ok another question/issue…
I’m now getting the following exception when running b/uber
1. Unhandled clojure.lang.ExceptionInfo
Unexpected lib file:
/Users/rick/.m2/repository/org/apache/jena/apache-jena-libs/3.10.0/apache-jena-libs-3.10.0.pom
{}
uber.clj: 182 clojure.tools.build.tasks.uber/explode
uber.clj: 141 clojure.tools.build.tasks.uber/explode
uber.clj: 257 clojure.tools.build.tasks.uber/uber/fn/fn
PersistentVector.java: 343 clojure.lang.PersistentVector/reduce
core.clj: 6829 clojure.core/reduce
core.clj: 6812 clojure.core/reduce
uber.clj: 256 clojure.tools.build.tasks.uber/uber/fn
protocols.clj: 49 clojure.core.protocols/iter-reduce
protocols.clj: 75 clojure.core.protocols/fn
protocols.clj: 75 clojure.core.protocols/fn
protocols.clj: 13 clojure.core.protocols/fn/G
core.clj: 6830 clojure.core/reduce
core.clj: 6812 clojure.core/reduce
uber.clj: 254 clojure.tools.build.tasks.uber/uber
uber.clj: 241 clojure.tools.build.tasks.uber/uber
Var.java: 384 clojure.lang.Var/invoke
api.clj: 394 clojure.tools.build.api/uber
api.clj: 339 clojure.tools.build.api/uber
REPL: 78 build/eval8865
REPL: 78 build/eval8865
Compiler.java: 7181 clojure.lang.Compiler/eval
Compiler.java: 7136 clojure.lang.Compiler/eval
core.clj: 3202 clojure.core/eval
core.clj: 3198 clojure.core/eval
interruptible_eval.clj: 87 nrepl.middleware.interruptible-eval/evaluate/fn/fn
AFn.java: 152 clojure.lang.AFn/applyToHelper
AFn.java: 144 clojure.lang.AFn/applyTo
core.clj: 667 clojure.core/apply
core.clj: 1977 clojure.core/with-bindings*
core.clj: 1977 clojure.core/with-bindings*
RestFn.java: 425 clojure.lang.RestFn/invoke
interruptible_eval.clj: 87 nrepl.middleware.interruptible-eval/evaluate/fn
main.clj: 437 clojure.main/repl/read-eval-print/fn
main.clj: 437 clojure.main/repl/read-eval-print
main.clj: 458 clojure.main/repl/fn
main.clj: 458 clojure.main/repl
main.clj: 368 clojure.main/repl
RestFn.java: 137 clojure.lang.RestFn/applyTo
core.clj: 667 clojure.core/apply
core.clj: 662 clojure.core/apply
regrow.clj: 20 refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
RestFn.java: 1523 clojure.lang.RestFn/invoke
interruptible_eval.clj: 84 nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj: 56 nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj: 152 nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
AFn.java: 22 clojure.lang.AFn/run
session.clj: 202 nrepl.middleware.session/session-exec/main-loop/fn
session.clj: 201 nrepl.middleware.session/session-exec/main-loop
AFn.java: 22 clojure.lang.AFn/run
Thread.java: 748 java.lang.Thread/runI think it’s because this particular transitive dependency doesn’t have a corresponding jar; it just declares dependencies: https://repo1.maven.org/maven2/org/apache/jena/apache-jena-libs/3.17.0/
Yeah poms can't get added to the classpath. This is in here to catch unexpected stuff. Maybe we should just ignore poms
Sorry to bother you, is there an issue for this?
I’m happy to create one
Summary of the issue: The problem manifests itself when building uberjars that contain deps whose pom.xml’s only reference dependencies (i.e. there is no corresponding jar for the classpath)
yes, please feel free now (and in every future case), to create a question on https://ask.clojure.org
Thanks — I’ll definitely do that in the future, I just wasn’t sure if you’d made an issue for it or not 🙇
I have not
even if I had, asking on ask would be ok :)
@zulip-mirror-bot has joined the channel
@logbot has joined the channel