Fork me on GitHub
#tools-build
<
2021-09-23
>
rickmoynihan10:09:29

In the tools.build example here: https://clojure.org/guides/tools_build#_compiled_uberjar_application_build Why write a pom to an uberjar??

rickmoynihan10:09:34

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.

pavlosmelissinos10:09:47

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

rickmoynihan10:09:57

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.

rickmoynihan10:09:15

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

rickmoynihan12:09:54

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

rickmoynihan12:09:59

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

rickmoynihan12:09:01

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

rickmoynihan12:09:03

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

seancorfield15:09:46

In my build-clj wrapper, you can omit :version and then uber skips the pom-writing.

rickmoynihan10:09:56

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.

mike_ananev10:09:14

@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.

rickmoynihan11:09:44

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…

seancorfield15:09:57

That was only true in 1.0. In 2.0 the classpath was built separately and depstar had whatever deps it needed.

👍 1
rickmoynihan11:09:19

Another tools.build 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

rickmoynihan12:09:02

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
rickmoynihan12:09:00

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

rickmoynihan12:09:05

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/run

rickmoynihan12:09:49

I 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/

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
rickmoynihan10:09:35

Sorry to bother you, is there an issue for this?

rickmoynihan10:09:40

I’m happy to create one

rickmoynihan13:10:26

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 https://ask.clojure.org

rickmoynihan13:10:41

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