lein ring uberwar ignoring :provided profile?

[TreeRex]

I'm creating an uberwar for my servlet. One of the libraries I'm using has a downstream dependency that brings in Guava. Unfortunately GlassFish also provides Guava, so when it gets bundled in my war GF is unable to start the servlet.

I thought the :provided profile was meant to cover this case. I have

:provided {:dependencies [[com.google.guava/guava "18.0"]]}

in my :profiles, which pulls in Guava when I'm running in the repl with the embedded server. All is good. But lein ring uberwar is including the Guava jar file in the war.

Have I misunderstood what :provided does?

The only fix I can think of is to move my dependency out of the "global" set and define it differently in the :dev profile and the :uberjar profile (I believe uberwar refers to uberjar), the former with an exclusion and the latter without.

[ekimber]

Typically, you would use provided for container libs such as the servlet API. Actually I don't think GlassFish shouldn't really be leaking guava into the classloader at all. That sounds like a bug in GlassFish.

But it should work pretty much as you describe, with guava in :provided and also excluded from the library in the main dependency list, as long as the two versions of guava are compatible. You shouldn't have to mess around with the profiles... although you may at that point hit the issue that I have discovered with :provided, where it works as expected with uberjar but it doesn't get put on the classpath for uberwar compilation, and doesn't compile.

[bilus]

I seem to have the same problem with "lein uberjar" after upgrading to Leiningen 2.5.2. On the other hand :scope "provided" set individually for each global dependency does work:

(defproject proton-auth "0.9.3"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url  "http://www.eclipse.org/legal/epl-v10.html"}

  ;; Most dependencies below are 'provided' because proton-auth is also used as a library (auth.api-conn).
  ;; Esp. pulling in buddy causes conflicts with BouncyCastle because it uses 1.52.
  :dependencies [[org.clojure/clojure "1.7.0" :scope "provided"]
                 [ring "1.4.0" :exclusions [ring/ring-jetty-adapter] :scope "provided"]
                 ;[ring/ring-jetty-adapter "1.4.0-RC2"]
                 [compojure "1.4.0" :scope "provided"]
                 [buddy "0.6.0" :scope "provided"]
                 [ring/ring-json "0.3.1" :scope "provided"]
                 [prismatic/schema "0.4.3" :scope "provided"]
                 [cheshire "5.5.0" :scope "provided"]
                 [yesql "0.4.2" :scope "provided"]
                 [org.postgresql/postgresql "9.4-1201-jdbc41" :scope "provided"]
                 [migratus "0.8.2" :scope "provided"]
                 [environ "1.0.0" :scope "provided"]
                 [http-kit "2.1.19" :scope "provided"]
                 [clj-http "2.0.0"]
                 [medley "0.7.0"]]
  :plugins [[lein-ring "0.9.6"]
            ;[quickie "0.4.0"]
            [com.jakemccrary/lein-test-refresh "0.10.0"]
            [migratus-lein "0.1.5"]
            [lein-environ "1.0.0"]
            [s3-wagon-private "1.1.2"]]
  :min-lein-version "2.5.0"
  :source-paths ["src"]
  :repositories {"s3private" {:url        "s3p://clj.repo/releases/"
                              :username   :env
                              :passphrase :env}}
  :main auth.core
  :uberjar-name "proton-auth.jar"
  :aliases {"quickie" ["with-profile" "dev" "quickie"]}
  :migratus {:store          :database
             :migrations-dir "migrations"}
  :profiles {:dev     {:dependencies [[ring/ring-mock "0.2.0"]]
                       :source-paths ["test"]}
             :uberjar {:aot :all}})

[curtosis]

This seems to be more generally that uberwar does not handle additional profiles. (There's some other weirdness in how :target-path "target/%s/" gets expanded as well, for both uberwar and uberjar.)

Original bug and test cases over here: technomancy/leiningen#2001

[MichaelBlume]

Nice work @curtosis, thanks =)

[hanshuebner]

I came up with this patch:

luminus-framework/lein-uberwar@34efc38

It works for me, but I'm not sure whether it is good enough for general use.

[MichaelBlume]

Hmm, sorry I'm coming at this so late, but I don't actually see anything
there?

On Thu, Jan 14, 2016 at 1:01 PM Hans Hübner notifications@github.com
wrote:

I came up with this patch:

luminus-framework/lein-uberwar@master...lambdawerk:master
luminus-framework/lein-uberwar@master...lambdawerk:master

It works for me, but I'm not sure whether it is good enough for general
use.

—
Reply to this email directly or view it on GitHub
#163 (comment)
.

[hanshuebner]

The change was merged since then, here is the closed PR: luminus-framework/lein-uberwar#2

…

-Hans ​

[johnmcconnell]

Just experienced this.

[johnmcconnell]

My work around was to make a bash script which manually deletes the library from the war