Fork me on GitHub

In the example here: 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.

Alex Miller (Clojure team)12:09:41

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.

Alex Miller (Clojure team)12:09:21

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.

Alex Miller (Clojure team)12:09:15

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?

Alex Miller (Clojure team)12:09:32

here - .pom files have no meaning in a classpath

Alex Miller (Clojure team)12:09:04

oh sorry, maybe not here


Also thanks again for everything 🙇 I’ve been enjoying trying to port some things over to


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.

👍 1

Another question… When would you want to b/compile-clj with :sort :bfs instead of :sort :topo?

Alex Miller (Clojure team)12:09:55

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?!

Alex Miller (Clojure team)12:09:36

That's topo - bfs is basically doing the compilation in lexica sort order

👍 1

Ok another question/issue… I’m now getting the following exception when running b/uber


1. Unhandled clojure.lang.ExceptionInfo
   Unexpected lib file:
                  uber.clj:  182
                  uber.clj:  141
                  uber.clj:  257  343  clojure.lang.PersistentVector/reduce
                  core.clj: 6829  clojure.core/reduce
                  core.clj: 6812  clojure.core/reduce
                  uber.clj:  256
             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
                  uber.clj:  241
          384  clojure.lang.Var/invoke
                   api.clj:  394
                   api.clj:  339
                      REPL:   78  build/eval8865
                      REPL:   78  build/eval8865
    7181  clojure.lang.Compiler/eval
    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
          152  clojure.lang.AFn/applyToHelper
          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*
       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
       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
      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
           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
           22  clojure.lang.AFn/run
       748  java.lang.Thread/run


I think it’s because this particular transitive dependency doesn’t have a corresponding jar; it just declares dependencies:

Alex Miller (Clojure team)12:09:12

Yeah poms can't get added to the classpath. This is in here to catch unexpected stuff. Maybe we should just ignore poms

👍 1

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)

Alex Miller (Clojure team)13:10:50

yes, please feel free now (and in every future case), to create a question on


Thanks — I’ll definitely do that in the future, I just wasn’t sure if you’d made an issue for it or not 🙇

Alex Miller (Clojure team)13:10:08

even if I had, asking on ask would be ok :)

👍 1