Fork me on GitHub
#boot
<
2016-06-10
>
richiardiandrea00:06:48

@seancorfield: I am on a crusade, PR-ing some lib in order to add [org.clojure/clojure "1.7.0" :scope "provided"] 😄

richiardiandrea00:06:07

I was testing drip again, and this way it actually makes a difference:

time drip -cp $(cat cp) clojure.main -e "(+ 1 3)"
4

real	0m1.035s
user	0m1.894s
sys	0m0.095s

time drip -cp $(cat cp) clojure.main -e "(+ 1 3)"
4

real	0m0.212s
user	0m0.062s
sys	0m0.043s

micha01:06:01

@richiardiandrea: i need to add the filtering step

micha01:06:41

currently it returns all conflicts it sees, even ones you resolve correctly by specifying a direct dependency that overrides the contested transitive one

micha01:06:12

it returns them because with show -p you want to see those; it marks them with a check mark in the fancy output to show that you resolved them

micha01:06:47

just need to filter thoseout

micha01:06:30

i'm not sure that :scope "provided" for widely used dependencies will help much

micha01:06:57

it seems like the only way to deal with it is to add a direct dependency for the version you want, or use :exclusions

richiardiandrea01:06:13

from what I can see here, for org.clojure/clojure is working (and makes sense right?)

micha01:06:35

if a library has a dependency with :scope "provided" maven will ignore it when it resolves transitive dependencies

micha01:06:07

but that's not necessarily a good thing

micha01:06:15

because it also hides it from tools like show -p

micha01:06:25

so if the library isn't working it's hard to know why

micha01:06:46

i don't know what the best answer is i guess

richiardiandrea01:06:04

yes that's true but imho it depends on the scenario, in case of Clojure I guess that you cannot rely on a transitive dep

micha01:06:05

just pointing out some issues with that way of managing the problem

micha01:06:21

yeah clojure is a special case i think

micha01:06:29

because the clojure api is very stable

micha01:06:45

but that's not a guarantee

richiardiandrea01:06:02

and you kind of should always specify it yourself explicitly right?

micha01:06:04

like you can be pretty confident that a library that uses clojure 1.2 will still work

micha01:06:15

so you don't care to investigate how it will work with 1.8

micha01:06:21

you just update the dep and move on

micha01:06:58

but if there were changes you needed to watch out for, using :scope "provided" would hide the version the library depends on from tools like show -p

micha01:06:13

so it would be harder to track down dependency issues

richiardiandrea01:06:39

valid point I guess

micha01:06:14

currently i am thinking the best way to deal with it is to specify your own version explicitly as a direct dependency, or to completely :exclusions it

micha01:06:44

also have you seen apache ivy?

micha01:06:53

it might be interesting to look at

richiardiandrea01:06:00

i'll have a look

micha01:06:11

it has a pluggable dependency resolution module system

micha01:06:22

it could work alongside aether, i think

micha01:06:39

i believe gradle used it a while back?

richiardiandrea01:06:02

oh nice, well today I went through some cleaning and it is not pleasant, so any better way is better 🙂

micha01:06:41

maybe ivy has some tools already written that can help with sortig out dependencies

micha01:06:55

in an automated way

richiardiandrea01:06:16

I guess the only real reliable test is to try it out, kind of hoping that libraries are following semver as well, so that patch numbers don't break anything important

richiardiandrea01:06:17

i downgraded a lot of deps today because they felt like a "common" denominator 😄

richiardiandrea01:06:46

then tried, nothing broke, tried tests, nothing broke

richiardiandrea01:06:53

still I am not confident

berrysoup12:06:23

Hi where can i find something working the same as maven-assembly-plugin in boot-clj? I mean build the whole package?

berrysoup13:06:13

@alandipert: Thanks a lot. I have done done jar file in my project but I would like to avoid writing the whole command: java -cp my-jar.jar [command] [options] because it is multiple main classes and I would like to keep log4j.xml outside the jar file. Thus command will be like: java -cp lib/my-jar;lib/log4j2.xml [command] [options]. I thought about giving a few shell scripts to make the call shorter. I thought about following project https://github.com/jgrzebyta/sesame-loader/

richiardiandrea19:06:53

I added the filter to boot-cp and I am working on adding an :exclusions options

richiardiandrea19:06:40

I was thinking of using this in a couple of project and these two things are necessary I guess...for the exclusion I was thinking of importing from: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj#L278

richiardiandrea19:06:06

is it the right place Micha?