Fork me on GitHub
#juxt
<
2018-05-16
>
dominicm05:05:31

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.

michal10:05:16

@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?

dominicm10:05:01

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.

michal10:05:33

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).

dominicm11:05:34

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.

dominicm11:05:40

I really want to enable caplets from pack.

michal11:05:49

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

dominicm11:05:07

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.

dominicm11:05:40

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

michal11:05:11

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.

dominicm11:05:03

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!).

dominicm11:05:47

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

michal11:05:25

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

dominicm11:05:09

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.

dominicm11:05:28

Oh, you're probably using figwheel outside of Krei

michal11:05:51

yes, I tried to minimize number of dependencies

dominicm11:05:14

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 🙂

michal11:05:36

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)

michal11:05:30

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

michal11:05:05

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

michal11:05:33

and use command line only to override them if needed

dominicm12:05:14

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.