boot

:boot-clj: https://boot-clj.github.io/ — build tooling for Clojure. Dev chat in #boot-dev
seancorfield 2018-06-07T17:19:42.000274Z

Folks, I'm trying to help @rcustodio with a boot-tools-deps issue and what we've run into is that his project has a locally built JAR file (Java code) that needs to get included into an uberjar -- but boot-tools-deps doesn't know how to tell Boot about it.

seancorfield 2018-06-07T17:21:07.000300Z

It can't go on :resource-paths (because Boot tries to copy "source files" from those locations -- and throws an exception if it gets a file, rather than a directory there, it seems). It can't go on :dependencies because it's not something Boot knows how to fetch.

seancorfield 2018-06-07T17:21:53.000308Z

Is it possible to use a locally built JAR that is not in a Maven repo (or the ~/.m2 cache) with boot ... uber ...

2018-06-07T18:04:37.000242Z

@seancorfield do i understand right that you want the jar's contents, not the .jar, to be added to the fileset and included in an uberjar?

seancorfield 2018-06-07T18:25:01.000193Z

@alandipert Yes, I think that would be the end game.

seancorfield 2018-06-07T18:25:32.000524Z

(so, treated just like a :dependency JAR that was downloaded)

seancorfield 2018-06-07T18:26:55.000564Z

For running the project, it's fine to just add it to the classpath (which boot-tools-deps does), but the uber / jar tasks don't pay attention to the classpath, only to :resource-paths and :dependencies (well, and :asset-paths).

dominicm 2018-06-09T17:51:10.000131Z

Ah, missed the nuances of that.

seancorfield 2018-06-07T18:28:27.000592Z

(personally, I'd just stick it in the local ~/.m2 cache after building it locally but I'm not sure how practical that is for @rcustodio’s workflow?)

2018-06-07T18:37:00.000710Z

yeah, i think that's probably the best way too. but in the past i seem to recall using some of the functions in the worker pod to unzip jars to the fileset

seancorfield 2018-06-07T18:44:11.000065Z

@rcustodio It might be simpler for you overall to just run mvn install in that imgscalr project and it will put 4.3.0-SNAPSHOT into your local Maven cache folder -- and then just depend on that version in your main project instead.

rcustodio 2018-06-07T18:44:37.000061Z

I see… thanks @seancorfield, I will do that

seancorfield 2018-06-07T18:45:00.000165Z

Although, that said, when I tried it, the tests failed so the install goal failed:

Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.354 sec <<< FAILURE!
testApply4(org.imgscalr.ScalrApplyTest)  Time elapsed: 0.125 sec  <<< FAILURE!
java.lang.AssertionError: expected:<-11842741> but was:<-11908534>

seancorfield 2018-06-07T18:48:56.000306Z

ant clean jar works (and produces a 4.2 versioned lib) so I guess you could build it that way and install it to ~/.m2 with https://github.com/seancorfield/boot-localrepo

seancorfield 2018-06-07T18:51:21.000396Z

So ant clean jar && boot -d seancorfield/boot-localrepo install-artifact -f dist/imgscalr-lib-4.2.jar -P org.imgscalr/imgscalr-lib -v 4.3.0-pre and then depend on org.imgscalr/imgscalr-lib "4.3.0-pre"

seancorfield 2018-06-07T18:51:57.000117Z

(using that name avoid the SNAPSHOT issues and also means you won't conflict with a real 4.3.0 release of the library later @rcustodio)

rcustodio 2018-06-07T18:58:21.000849Z

Thanks @seancorfield