Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-01

Channels

#tools-deps
<
2019-05-01
>
luposlip07:05:32

deps.edn newbie here: Anyone's got some intelligent input to the following issue, where a working lein based project, using a java library hosted on jitpack, doesn't work when used via deps.edn (dependency tree doesn't get resolved)? https://github.com/luposlip/json-schema/issues/1

dominicm07:05:44

@luposlip you need to put jitpack in your :mvn/repos

luposlip07:05:24

even when it's already referred to by the json-schema library? The user wants to use json-schema, which already refers to jitpack, from a project using deps.edn.

dominicm07:05:35

I'm not sure that deps can pick those up, there might be a jira.

luposlip08:05:48

Hmm.. When a library is packaged and deployed to clojars it normally works out of the box when using it from another lein project, regardless of the dependencies and where they are stored. If this is not the case with clj + deps.edn it seems like a showstopper to me.

luposlip08:05:53

Ahh, thanks for the link!

luposlip08:05:06

I'll follow that jira! 馃檪

dominicm08:05:27

Your vote will help with setting priority

luposlip08:05:55

I will upvote it!

kszabo23:05:28

hey, moving from boot to tools-deps + kaocha, which of the many uberjar building tools do you recommend to replace boot鈥檚 capabilities? I see several but see no consensus from the community on which is the most stable / can expect future maintenance.

kenny23:05:33

We've been using https://github.com/seancorfield/depstar in production for several months now. Does the job.

kszabo23:05:00

thanks, but I just noticed that it doesn鈥檛 do AOT, guess I鈥檒l need to add that to the list of required features so that the build tooling change does not change the produced artifact

kszabo23:05:35

It seems badigeon will fit our needs, thanks!

seancorfield23:05:11

AOT is evil 馃檪

鉁旓笍 4
kenny00:05:06

Yep - we stopped AOT'ing our code when we moved over from Boot. Too many headaches.

seancorfield00:05:32

We stopped AOT'ing long before that 馃檪 Hence depstar does exactly as much as we need: build a JAR from the classpath. In production we do java -cp /path/to/the.jar clojure.main -m our.entry.point

donaldball01:05:35

What is the current reason to consider AOT evil? We鈥檝e just started using it for our service uberjars to shave a modest but meaningful time off of startup time.

seancorfield03:05:04

If you're using it as the very last stage, to produce an uberjar, and you really need it to improve startup time, that's "fine". But the Leiningen default where the main namespace is :gen-class'd and AOT is the default in project.clj just gets beginnners into a mess -- and it is completely unnecessary. AOT overall is completely unnecessary -- unless you really, really care about startup time for a final production artifact.

seancorfield03:05:20

AOT's transitive compilation issues and the problems you can run into when you end up with a mix of .class and .clj versions of the same file can be hell to debug. Much better to just avoid all of that, unless you know what you're doing and you see AOT as purely an end-of-the-line optimization.

seancorfield03:05:53

The biggest overhead for us at startup time is New Relic's Java agent instrumenting classes (since Clojure generates so many).

seancorfield03:05:15

And since nearly all of our processes are long-running, we just don't care about startup time.

kenny15:05:00

I could see it mattering more if you need to scale your service quickly due to large demand spikes.

kszabo17:05:28

In the end I took your advice and did not AOT before uberjaring. Still I stayed with badigeon because it allowed me to exclude some cljs related files I don鈥檛 need from my resources, which sadly depstar doesn鈥檛 support, having a static exclude function.

seancorfield17:05:07

Feel free to create an issue for depstar to exclude files -- I just refactored some of that code recently so it'll be easier to extend to support options (although, right now, depstar has no command-line options at all beyond the JAR filename).