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

bin/lein uberjar on stable source tree dies in infinite recursion #2198

Closed
kentfredric opened this issue Sep 4, 2016 · 8 comments
Closed
Labels

Comments

@kentfredric
Copy link

Currently trying to work out how to build leiningen from sources ( Because I'm packaging for Gentoo, and Gentoo desires everything to be built from sources wherever possible ).

However, this results in a problem wherein, using lein-2.7.0-standalone.jar (provided by you) to compile lein-2.7.0-standalone.jar from lein-2.7.0.tar.gz following instructions ends in infinite recursion compiling release.clj

13707  tar -xf /usr/portage/distfiles/leiningen-2.7.0.tar.gz 
13708  cd leiningen-2.7.0/
13709  cd leiningen-core/
13710  ls
13711  lein bootstrap
13712  cd ../
13713  bin/lein uberjar
 bin/lein uberjar
Recalculating Leiningen's classpath.
Compiling leiningen.search
Compiling leiningen.core.utils
Compiling leiningen.core.main
Compiling leiningen.core.user
Compiling leiningen.core.ssl
Compiling leiningen.core.eval
Compiling leiningen.core.classpath
Compiling leiningen.core.project
Compiling leiningen.do
Compiling leiningen.plugin
Compiling leiningen.vcs
Compiling leiningen.trampoline
Compiling leiningen.clean
Compiling leiningen.help
Compiling leiningen.deps
Compiling leiningen.change
Compiling leiningen.uberjar
Compiling leiningen.check
Compiling leiningen.update-in
Compiling leiningen.retest
Compiling leiningen.new.plugin
Compiling leiningen.new.default
Compiling leiningen.new.templates
Compiling leiningen.new.template
Compiling leiningen.new.app
Compiling leiningen.test
Compiling leiningen.release
nil
Exception in thread "main" java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:348)
....<SNIP>
Caused by: java.lang.StackOverflowError, compiling:(leiningen/release.clj:64:5)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6875)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$ThrowExpr$Parser.parse(Compiler.java:2429)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$CaseExpr$Parser.parse(Compiler.java:8768)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.access$300(Compiler.java:38)
        at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:589)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
        at clojure.lang.Compiler.analyze(Compiler.java:6669)
        at clojure.lang.Compiler.analyze(Compiler.java:6625)
        at clojure.lang.Compiler.eval(Compiler.java:6931)
        at clojure.lang.Compiler.load(Compiler.java:7379)
        at leiningen.release$eval26845.invokeStatic(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:141)
        at leiningen.release$eval26845.invoke(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:138)
        at clojure.lang.Compiler.eval(Compiler.java:6927)
        at clojure.lang.Compiler.load(Compiler.java:7379)
        at leiningen.release$eval26794.invokeStatic(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:141)
        at leiningen.release$eval26794.invoke(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:138)
        at clojure.lang.Compiler.eval(Compiler.java:6927)
        at clojure.lang.Compiler.load(Compiler.java:7379)
        at leiningen.release$eval26743.invokeStatic(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:141)
        at leiningen.release$eval26743.invoke(file:/tmp/lein/leiningen-2.7.0/src/leiningen/release.clj:138)
        at clojure.lang.Compiler.eval(Compiler.java:6927)
        at clojure.lang.Compiler.load(Compiler.java:7379)
<SNIP>

Blindly nuking this block of code makes it "compile", alas, with far fewer files in the final JAR than one expects.

https://github.com/technomancy/leiningen/blob/master/src/leiningen/release.clj#L136-L142

;; support existing release plugin:
;; https://github.com/technomancy/leiningen/issues/1544
(when-let [[resource] (-> (.getContextClassLoader (Thread/currentThread))
                          (.getResources "leiningen/release.clj")
                          (enumeration-seq) (distinct) (rest) (seq))]
    (clojure.lang.Compiler/load (io/reader resource)
                                "leiningen/release.clj" (str resource)))

Its not clear what I should be doing here to resolve this.

@hypirion hypirion added the bug label Sep 4, 2016
@hypirion
Copy link
Collaborator

hypirion commented Sep 4, 2016

I tried to reproduce this with the exact same steps, but I couldn't do it on Debian Jessie. Could you provide the JVM version you use as well? (I build on 1.6.x) Also, is there anything in your ~/.lein/profiles.clj/~/.lein/profiles.d/*?

Either way, the attempted fix for #1544 could probably be reverted because it seems iffy when we uberjar, especially because this is should be a noop during compile time.

@kentfredric
Copy link
Author

So far tested on OpenJDK 7 ( 1.7.0_111 ) and OpenJDK 8 ( 1.8.0_101 )

Don't have 1.6 handy for comparison.

Also was producing the problem where ~/.lein did not exist.

The only thing I think may be related is the $PATH/ lein used for bootstrap is infact a lein-pkg, not a lein. ( I believe I tried testing with non-pkg lein , but I tried so many different things before finally giving up that I can't say for sure )

@hypirion
Copy link
Collaborator

hypirion commented Sep 6, 2016

That sounds suspicious – I'll see if I can get some time to try and reproduce this tomorrow, but there shouldn't be any reason for this to not work.

@canhduong28
Copy link

canhduong28 commented Sep 9, 2016

I also had an issue with installing deps/plugins by leiningen v2.7.0

Retrieving org/clojure/google-closure-library/0.0-20151016-61277aea/google-closure-library-0.0-20151016-61277aea.jar from central
Retrieving com/google/javascript/closure-compiler/v20151216/closure-compiler-v20151216.jar from central
Retrieving org/mozilla/rhino/1.7R5/rhino-1.7R5.jar from central
Retrieving org/clojure/clojure/1.7.0/clojure-1.7.0.jar from central
Could not transfer artifact org.clojure:clojure:jar:1.7.0 from/to central (https://repo1.maven.org/maven2/): GET request of: org/clojure/clojure/1.7.0/clojure-1.7.0.jar from central failed
Could not find artifact org.clojure:clojure:jar:1.7.0 in clojars (https://clojars.org/repo/)
Could not transfer artifact com.google.javascript:closure-compiler:jar:v20151216 from/to central (https://repo1.maven.org/maven2/): GET request of: com/google/javascript/closure-compiler/v20151216/closure-compiler-v20151216.jar from central failed
Could not find artifact com.google.javascript:closure-compiler:jar:v20151216 in clojars (https://clojars.org/repo/)
Could not transfer artifact org.clojure:google-closure-library:jar:0.0-20151016-61277aea from/to central (https://repo1.maven.org/maven2/): GET request of: org/clojure/google-closure-library/0.0-20151016-61277aea/google-closure-library-0.0-20151016-61277aea.jar from central failed
Could not find artifact org.clojure:google-closure-library:jar:0.0-20151016-61277aea in clojars (https://clojars.org/repo/)
Could not transfer artifact org.mozilla:rhino:jar:1.7R5 from/to central (https://repo1.maven.org/maven2/): GET request of: org/mozilla/rhino/1.7R5/rhino-1.7R5.jar from central failed
Could not find artifact org.mozilla:rhino:jar:1.7R5 in clojars (https://clojars.org/repo/)
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment variable. 

here is my project.clj

(defproject twitter-bot "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.8.0"]]
  :plugins [[lein-cljfmt "0.5.3"]]
  :main twitter-bot.core)

@hypirion
Copy link
Collaborator

@nautilus28: This seems to be a different issue than what is described here – it may look like that is a temporary maven central outage. If you see this again could you make a new issue for this?

@canhduong28
Copy link

@hypirion yep my bad, it was a temporary maven central outage. Now it works fine. Thanks.

@firesofmay
Copy link

@hypirion Is this still an open issue or we can close this?

@technomancy
Copy link
Owner

Wow, this is a gnarly piece of bending-over-backwards-compatibility indeed.

However, I pushed a fix that should take care of the infinite recursion.

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

5 participants