hi, I am trying to build skinny jar with pack and got this error:

Exception in thread "main" java.lang.IllegalArgumentException: No matching clause: [nil :jar]
	at mach.pack.alpha.skinny$run_steps.invokeStatic(skinny.clj:107)
	at mach.pack.alpha.skinny$run_steps.invoke(skinny.clj:99)
	at mach.pack.alpha.skinny$_main.invokeStatic(skinny.clj:175)
	at mach.pack.alpha.skinny$_main.doInvoke(skinny.clj:158)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.core$apply.invokeStatic(core.clj:657)
	at clojure.main$main_opt.invokeStatic(main.clj:317)
	at clojure.main$main_opt.invoke(main.clj:313)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)

but jar is created

please advice what I am doing wrong

pack version:

{pack/pack.alpha {:git/url ""
                                       :sha "ddbbdbd4001c75647deddaad0f8bb7dc954fcb6f"}}

UPD: I switched to latest version in master and everything seems to work

one thing tho - skinnyjar stucks if target directory contains prev version…

@kirill.salykin master is a pretty big rewrite of pack. This bug isn't terribly surprising 😊 What do you mean by "contains previous version"?

if you run it twice in a row

`

rm -rf ./target/*
clojure -A:pack mach.pack.alpha.skinny

this fixes it

@kirill.salykin what is the output in the case that it gets stuck? I expect a thread will error something?

no output, just takes a lot of time

more then 1 minute on machine

i was not patient to wait longer…

Hmm. I'll try and debug that today. I'm not sure what could cause that.

if you clean the target directory - everything works perfectly

Maybe there's something accidentally recursive.

shall I create the issue?

Feel free, I'll try and get round to it today 🙂

will do, thanks for your help!

@kirill.salykin I'm unable to reproduce what you're seeing 😟 I might need some more context, maybe it only happens under certain deps.edn files or something?

I’ll try to create some minimal repro case

thanks for looking

I'll mirror this on github 🙂 Not sure which channel you prefer for tracking this

fwiw, I tested against pack itself like this: clojure -m mach.pack.alpha.skinny --lib-dir /tmp/lib --project-path skinny.jar

maybe it is something in our project

What does your :pack alias look like?

hm

:pack {:extra-deps {pack/pack.alpha {:git/url ""
                                       :sha "4a00565dce29225a1dd2a810c438b90b14f9e111"}}
         :main-opts ["-m"]}}}

I am bit confused with empty main-opts

lemme try w/o main-opts at all

@kirill.salykin it really just saves you from typing -m 😄

so it doesnt matter?

not particularly 🙂

works on empty project I assume it is something within my project

if you can track down what's within your project, I'd be interested

I’ll try, but later. It seems not urgent, also it is nice to clean target directory anyway (for outdated libs for instance) so not with rm -rf target/* it just works

btw, pack dies if target directory not created

Question regarding juxt/pack, do I understand correctly that using --lib-type keep with skinny-jar should keep clojure file in jar? the issue I see now that git dependency packed as empty jar (there is no gen-class) and clojure complaints that can find file on classpath

@kirill.salykin --lib-type keep means that any dependencies that are jars, will stay as jars, and git dependencies which are directories, will stay as directories.

is it by design that git dependency packed into empty jar? or do I missing something in config?

that sounds wrong. I haven't seen that in my testing

will try to create something that can reproduce the issue

thanks!

@kirill.salykin my mistake, I've reproduced

working on it

Thanks!

i've got a lein-modules based project in a monorepo which has common deps in the top-level project.clj and per-module deps in each module subdirs own project.clj. it builds and tests all modules in a sensible (poset) order and correctly outputs versioned jars for each module - is there a way of achieving similar behaviour for deps.edn based project ?

@mccraigmccraig what's poset order? I would just loop over each directory with bash & use pack 😄

it figures out the correct order itself, based on the dependency graph

@kirill.salykin I've figured it out, dumb typo

@kirill.salykin Try 24863d1ff5a54bb7cc783ff62272212b51c8b316

wow, it blazingly fast, thanks! trying

@kirill.salykin I go on holiday soon, and I've wrapped up work 🙂 I have a few spare cycles.

yay! works! thanks

Great 🙂

btw, stuck issue seems fixed as well

oh, hmm :thinking_face:

¯\(ツ)/¯

I ran into some trouble using java9+ and Cider with deps. Deps builds abbreviated paths ("src", as specified in :paths) instead of full paths ("/home/rpkarlsson/Projects/mc-kartan/src/") as other classpath builders seem to do. Cider with java1.8 and lower determines the classpath in a different manner and is not effected by this. Are abbreviated paths something that could potentially lead to other problems and because of that should be fixed in deps or should abbreviated paths be expected in tooling? More info at: https://github.com/clojure-emacs/cider/issues/2533

Comments, sugestions? https://dev.clojure.org/jira/browse/TDEPS-56?focusedCommentId=50940&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50940

I've got the spaces work in :main-opts

Looks reasonable to me, personally, though I'd prefer newlines to NUL characters.

¯\(ツ)/¯

I’m not playing the game of uploading competing patches

if there are competing approaches, please summarize the tradeoffs

I need that to make decisions and I will have a slice of time to do so soon