juxt

dominicm 2018-05-16T05:33:31.000091Z

Dependencies have the jar name from after the group. Both foo/bar and baz/bar have a jar named bar.jar. To prevent them conflicting the sha is added to make them unique.

michal 2018-05-16T10:48:16.000231Z

@dominicm thanks for that explanation, it makes sense. just one more question regarding pack.alpha - how it's licensed? I couldn't find that info on github and I would like to reuse some of your solutions (like the one to create uberjar) in my own tool (open-sourced). is it enough to let people know about original author and point to your github repo?

dominicm 2018-05-16T10:50:01.000010Z

I haven't licensed it officially yet. I am leaning towards MPLv2, but need to check it over with any client contracts to make sure it wouldn't stop them from using it. @michal any reason you can't consume pack as a library? I'd rather like to support that.

michal 2018-05-16T10:59:33.000477Z

I also considered that, but actually the only think I need is classpath-string->jar function which creates an uberjar. And it would be also ok to use it directly from library, but this function creates a very specific manifest which I can't extend easily (eg. for caplets).

dominicm 2018-05-16T11:00:34.000280Z

I'd very much welcome a PR to do extend it more easily. That I haven't is just because I haven't had a concrete idea of what it should look like.

dominicm 2018-05-16T11:00:40.000274Z

I really want to enable caplets from pack.

michal 2018-05-16T11:03:49.000413Z

oh, in this case I will try then to extend this function and suggest a PR

dominicm 2018-05-16T11:04:07.000455Z

If you do choose to copy it into your repo, in the case I go with MPL, the only limitation is that, I think, you have to keep it in a separate file in order to license your code separately. You can even make it closed source in that case.

dominicm 2018-05-16T11:04:40.000243Z

But you have to keep the file containing code from pack.alpha open source, but it's not "infectious" like GPL

michal 2018-05-16T11:08:11.000032Z

great, thanks. I will consider again both options but, as you mentioned, seems like it would be better to add caplets directly to your repo and pull it as a dependency in my tool.

dominicm 2018-05-16T11:10:03.000344Z

https://github.com/juxt/pack.alpha/blob/master/docs/adr/001-input.adoc I tried to write up some thinking about parameters here, it's not accurate to actual implementation, and I think the decision is a bad idea in some ways, but the problem highlighting is correct at least (I think! Tell me if I've missed something!).

dominicm 2018-05-16T11:11:47.000402Z

@michal I'm curious to know what you're building, if you can share? 🙂

michal 2018-05-16T11:25:25.000457Z

sure. I was very impressed by your edge project basing on newest tools but the thing I didn't like was the amount of code required to configure all the elements together (like rebel, nrepl, figwheel and so on...). I thought I will create a simple plugins/tasks based "trampoline" which will fire all these elements behind the scenes, basing on simple configuration file, which would be pretty much more re-usable (at least for me...) and would also fix some of the problems that egde had (like double refresh in figwheel), will give much more control over certain tasks (like what directories to watch for changes, which to exclude) and allow to create a final artifact (a capsule) with API docs (based on codox). it's in very early development stage, but here you find a bit more details: https://github.com/mbuczko/revolt

dominicm 2018-05-16T11:32:09.000466Z

The figwheel refresh bug is due to the lack of debounce in the fs watcher, it's on my todo list. If you have a fix, I'd, again, appreciate a PR 😛. A version of edge with those features would be nice.

dominicm 2018-05-16T11:32:28.000419Z

Oh, you're probably using figwheel outside of Krei

michal 2018-05-16T11:32:51.000277Z

yes, I tried to minimize number of dependencies

dominicm 2018-05-16T11:33:14.000061Z

I'll look through revolt, I'm not fully convinced krei is a good idea in it's current form. So definitely curious to see how you're approaching this 🙂

michal 2018-05-16T11:39:36.000380Z

I wanted to have a something boot-like, where having a repl opened, I could manipulate with simple tasks to achieve everything I need during a development. eg, this is what I want to call to get a ready-to-use capsule, straight from repl:

(require '[revolt.task :as t])
(t/require-task ::t/info  :as info)
(t/require-task ::t/codox :as codox)
(t/require-task ::t/capsule :as capsule)

(-> info codox capsule)

michal 2018-05-16T11:40:30.000165Z

on the other hand, these task will be also callable straight from command line (like in your pack.alpha)

michal 2018-05-16T11:41:05.000286Z

but instead of providing so much of configuration details in command line I decided to put them into a configuration file

michal 2018-05-16T11:41:33.000173Z

and use command line only to override them if needed

dominicm 2018-05-16T12:41:14.000162Z

config vs command line has been a tugging debate in my head 🙂 I'm definitely interested to see how it goes with config for you.