Clojurians Log v2

Any idea why an uberjar build would get stuck on "Copying pom.xml to META-INF/maven/citadel/citadel/pom.xml"? It ran for 10 minutes before the CI killed the job. I can repro it locally too. Ran like this. v1.1.128

clojure -J-Dclojure.main.report=stderr -R:uberjar -m hf.depstar.uberjar citadel-standalone.jar -C --main cs.citadel --verbose

@kenny Since that's the last thing it does before exiting, I wonder if you have some top-level defs in your code that are kicking off execution of something that is preventing the process from terminating?

Is your project somewhere public, where I can take a look?

That does seem possible and definitely needs to be fixed. It's something new occurring in an absolutely massive PR. Unfortunately is proprietary code. Any thoughts on how to find something like that if that was the issue?

If it is successfully building the JAR before that PR and "hanging" on building the JAR with that PR in place, that would clearly point at something in the PR. Beyond that, pretty much impossible to tell without access to the code.

Yep. Current PR changes: +8,643 −5,343 😅

Curious as to why that's the location of the pause in uberjar build though. I would've thought it'd occur during compilation.

Sounds like it is hanging at exit -- which is common if your code is starting up processes when namespaces are loaded (as in compilation).

Try removing the -C --main cs.citadel options and seeing if it'll complete in a timely manner -- that would just copy code without loading any namespaces, and that would confirm it is some top-level def in the PR.

Yep - no hang with that. Shoot, this will be quite the search...

At least you're only looking for top-level def forms that were added (or changed)... 🙂

Or a top-level block of code I guess (even worse).

Comment stuff out until it works. Tried and true method 🙂 Thankfully the feedback cycle is only 15-20s.

depstar doesn't (currently) call (shutdown-agents) which it probably should when AOT is requested, which might mitigate this problem in some situations -- but it's better not to have to do that 😐

Worked it all the way back using the comment method. Adding uncomplicate.neanderthal.native to my require hangs the jvm. Commenting it out succeeds with no hang.

No clue why. We did bump the neanderthal version in this PR so that must be it.

If you want to try a quick tweak I committed: seancorfield/depstar {:git/url "<https://github.com/seancorfield/depstar>" :sha "2a5b903fa249ac42ace66a875b6eba1b29fe1519"} -- that calls (shutdown-agents) at the end.

That'd only cause a hang for 30 or 60s right?

Yeah, up to 60 seconds, but I figured it might be worth a try.

Worked it back to the neanderthal version now. 0.35.0 works and 0.36.0 and later hang.

This looks awfully suspicious: https://github.com/uncomplicate/neanderthal/compare/0.35.0..0.36.0#diff-b91149db483e701376ea3134542bfcf8439747f06acc873396e7510baa161b6aR10

^ diff between 0.35.0 and 0.36.0. Will try your tweak real quick.

Ha! That was it! Using the depstar with shutdown-agents doesn't cause any hang.

Naughty code in Neanderthal there but glad to hear the depstar tweak fixed it. I'll cut 1.1.132 later today I expect with that fix in it (and then I'll update clj-new to use that updated version 🙂 )

That is quite odd. That lib does some crazy stuff so I'll give him the benefit of the doubt 🙂

Anyway, thanks for the help Sean 🙂

I’m new to depstar and I’m having trouble understanding how transitive dependencies are packaged into a jar file. I’m building a library that depends on ring/ring-codec (a maven dependency), but the generated jar file does not include the transitive dependency. Is this by design? If so, are consumers of my lib required to add a dependency on ring-codec themselves? Here’s how I invoke depstar: clojure -M:depstar -m hf.depstar.jar janus.jar. My lib’s deps.edn has a :deps section that mentions ring-codec. The alias for depstar itself is straight from the github README.

Uberjars get transitive dependencies. Thin jars get just the project source code.

This is the exact same behavior as Leiningen and Boot, which also both produce thin jars and uberjars.

@cch1 does that help?