Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uberjar does not resolve from profile-vector #1833

Closed
chrisbetz opened this issue Feb 13, 2015 · 4 comments
Closed

uberjar does not resolve from profile-vector #1833

chrisbetz opened this issue Feb 13, 2015 · 4 comments
Labels

Comments

@chrisbetz
Copy link

Hi,

I got something like

:profiles {:a {:dependencies [[a "1"]]}
               :b {:dependencies [[b "1"]]}
               :uberjar [:a :b]
}

This does not resolve correctly (classes from a and b are missing while compling my project in uberjar).

It does work if i reference the dependencies in uberjar profile directly.

@hypirion
Copy link
Collaborator

Hi,

Does this work if you make :a and :b leaky? like so

:profiles {:a ^:leaky {:dependencies [[a "1"]]}
           :b ^:leaky {:dependencies [[b "1"]]}
           :uberjar [:a :b]
}

@chrisbetz
Copy link
Author

Hi,

thanks for the tip, leaky does the trick, so I'm fine for now.

However, as other tasks (like lein classpath or lein deps :tree) are working correctly without the profiles being leaky, I would suggest changing the behaviour of lein uberjar here, as it's inconsistent.

Cheers,

Chris

chrisbetz pushed a commit to gorillalabs/sparkling that referenced this issue Feb 16, 2015
@hypirion
Copy link
Collaborator

Yeah, I agree that the current functionality is a bit counter-intuitive.

@hypirion hypirion added the bug label Feb 16, 2015
chrisbetz pushed a commit to gorillalabs/sparkling that referenced this issue Feb 18, 2015
* master:
  added 1.1.0 to Release Notes
  release 1.1.0
  fixing project.clj (see technomancy/leiningen#1833)
  working on save-avro-file, not finished yet
  added sparkling.core namespace with functions using more clojureseq order of arguments. corrected order of functions in file to be more readable corrected naming of args to be more readable rewired sparkling.api to delegate everything to sparkling.core, so even if you're using the now deprecated sparkling.api, you're using the new api under the hood. did not(!) change tests, as this should also test new api.
  move to Spark 1.2.1, cleaned up project.clj: Now we test with Spark 1.1.0 and Spark 1.2.1 (which has some problems in my production setting, so I'm not using it currently), Hadoop 2.6.0, Avro 1.7.7
  fixed that annoying test
  updated dependencies, better profile-support
  added Spark 1.2.0 support, is tested in travis.
  Remove duplicate function definition.
  fixed requireNamespace (e.g. for clojure.lang.Keyword)
  used IFn instead AFunction for serialization. removed Flambo naming removed duplicate use of sparkling.kryo (class and package)
  removed unneccessary line in .travis.yml
@glts
Copy link
Collaborator

glts commented May 31, 2019

In Leiningen 2.9.1, uberjar does seem to pick up these dependencies. With a minimal project.clj,

(defproject repro "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.10.0"]]
  :profiles {:a {:dependencies [[clj-time "0.15.0"]]}
             :b {:dependencies [[http-kit "2.3.0"]]}
             :uberjar [:a :b]})

everything (clj-time, http-kit, Clojure, plus transitive deps) gets packaged into the uberjar, no ^:leaky annotation necessary.

Suppose this got fixed somewhere along the way, else we need more info on the repro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants