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

Lein uberjar producing different results to jar in different environments ( Ubuntu vs. OS X ) #2801

Open
huima opened this issue Aug 15, 2022 · 5 comments

Comments

@huima
Copy link

huima commented Aug 15, 2022

Hi,

last week we started to see a peculiar phenomenon, where Leiningen behaved differently in different environments. We haven't yet had time to debug the issue further, so can't yet pinpoint what could be the culprit.

We started to see two very different strange behaviours:

  1. Built uberjars started to fail with Clojure tools logging classes missing

  2. One project started in uberjar build to consume the whole available disk space

Both of these problems went away in Github Actions if we selected older Leiningen 2.9.4 to be used in the build.

Ubuntu-latest image on Github is Ubuntu 20.04.4 LTS version. It has 2.9.9 as the default version, but we also tested versions 2.9.10 and 2.9.8. Used java version was: Java 11.0.16 OpenJDK 64-Bit Server VM

For the first case, we started to see the following error, when the app started:

" Exception in thread "main" java.lang.NoClassDefFoundError: clojure/tools/logging/impl/LoggerFactory"

This was also confirmed from the built jar that the related class files were missing.

ls clojure/tools/logging/
impl.clj readable.clj test.cljImage

Whereas uberjar compiled with version 2.9.4 on Ubuntu had related class files there and worked.

On my local OS X Leiningen 2.9.8 also produces working uberjar.

ls clojure/tools/logging/impl/Logger
Logger.class         LoggerFactory.class

For the second issue, we started to see another project uberjar task take a very long time and consumes the available disk space of the machine. This was also confirmed on one development laptop, where we did not wait for the disk to get filled - but stopped the process as it looked to be taking way way way longer than normally.

We haven't yet investigated these issues more as we could go around the problem with the older version, but I thought about making this known - if someone else stumbles upon similar issues. Also, any thoughts on how to debug the issue more are appreciated.

@technomancy
Copy link
Owner

technomancy commented Aug 15, 2022

Yes, version 2.9.9 had a serious bug in it. What happens if you use the latest release?

@huima
Copy link
Author

huima commented Aug 16, 2022

Yes, version 2.9.9 had a serious bug in it. What happens if you use the latest release?

We also tested 2.9.10 and it behaved in the same way in the github ubuntu. Hence we tried to find earlier version that seemed to work.

@technomancy
Copy link
Owner

I see; well that's another matter entirely then.

Would be very interested in a repro case for this.

@technomancy
Copy link
Owner

Please, if you can provide a way to reproduce this problem, I would like to look into it, but there's nothing I can do with the information you've given so far.

@technomancy
Copy link
Owner

I would like to cut a release soon, so if you can provide instructions on how to reproduce this problem it would be helpful.

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

No branches or pull requests

2 participants