Clojurians
#clojure
<
2016-03-27
>

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

lumengxi00:03:02

anyone knows how to workaround this issue? https://github.com/lshift/cloverage/issues/83

lumengxi00:03:23

i cannot make lein cloverage work with my project

hiredman02:03:22

lumengxi: check 'lein deps :tee' you likely have some conflicting versions of some libraries being required

hiredman02:03:23

the cloverage lein plugin adds a dep on the cloverage library, which does some aot compiling, so that is going to break and cause problems for someone at some point, it may be you now

hiredman02:03:08

clojars really should have a "download artifact" link on the webpage

hiredman02:03:29

I bet if you crack open the cloverage 1.0.6 jar it is full of compiled class files for different versions of libraries you are also using in your project that is broken

hiredman02:03:04

huh, I was sure that was a good bet, but I am wrong

hiredman02:03:45

are you aot compiling? you may have stale cheshire class files from cheshire version X, which depends on jackson version J, but then the cloverage chesire dependency is overriding yours, so you get cheshire version Y and jackson version W, but for reasons`` the class files for version X are loaded instead of the code for version Y, and the class files for cheshire version X need jackson version J, which aren't there (because there is nothing in the dependency graph that needs them)

hiredman02:03:20

delete target/ and stop aot compiling if that is the case

lumengxi05:03:31

@hiredman: thanks for helping out! i do not use cheshire in my project actually, but i did delete target and stop aot compiling, still hit the same error. :disappointed:

hiredman06:03:38

@lumengxi: if you add an explicit dependency on the cloverage library (not the plugin) 'lein deps :tree' should correctly show you the conflicts that exist, you will almost certainly find that some library you are using depends on cheshire and is aot compiled

hiredman06:03:19

actually, it may that, but without the aot, at some point the maven coordinates for jackson changed, which means you could end up with two versions on the classpath on the same time

lumengxi07:03:22

@hiredman: thanks man found the problem, seems to be related to amazonica, I added [com.fasterxml.jackson.core/jackson-core "2.5.4”] and it works!

amacdougall19:03:38

I'm having an odd problem with leiningen. Previously, I had a Luminus-derived project.clj whose profiles looked like this:

:dev [:project/dev :profiles/dev]
:test [:project/test :profiles/test]
:project/dev { ... lots of stuff, deps, plugins, etc}
:profiles/dev {... some defaults for things that are normally in profiles.clj...}
:project/test { ... lots of stuff, deps, plugins, etc}
:profiles/test {... some defaults for things that are normally in profiles.clj...}
Because of reasons I'm too lazy to explain here, I decided to simplify to:
:dev {:dependencies {...}, :plugins {...}, ...} ; obviously multi-line in real life
:test ...ditto...

amacdougall19:03:24

But now commands like lein test or lein figwheel are acting as if the profiles aren't being read at all, even if I force a profile with with-profiles. When I check with lein show-profiles, the profiles I have defined do show up.

amacdougall19:03:56

Does anyone have advice? This is some weird stuff. If I move everything into project plugins/dependencies, it all works again.

amacdougall19:03:28

Oh, I think I get it... as a result of this, the version defined in profiles.clj is completely replacing the one in project.clj. Bleh.

amacdougall19:03:25

So the original approached used https://github.com/technomancy/leiningen/blob/stable/doc/PROFILES.md#composite-profiles, which was in fact the best solution here. The issue is that when you do that, the resulting list of :builds is a list instead of a vector, for some internal Leiningen reason... and then doo expects a vector explicitly, and ugh. I have a feeling this is Leiningen's fault.

amacdougall19:03:22

I guess the real question is whether client code should always assume that an ordered collection might be either a list or a vec? That seems to defy the design considerations baked into Clojure.