This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-16
Channels
- # architecture (12)
- # aws (8)
- # bangalore-clj (1)
- # beginners (172)
- # boot (25)
- # chestnut (3)
- # cider (15)
- # cljsrn (5)
- # clojure (170)
- # clojure-india (1)
- # clojure-italy (21)
- # clojure-nl (87)
- # clojure-romania (3)
- # clojure-sg (1)
- # clojure-spec (1)
- # clojure-uk (79)
- # clojurescript (79)
- # cursive (2)
- # datomic (29)
- # dirac (26)
- # emacs (7)
- # fulcro (13)
- # jobs (4)
- # juxt (22)
- # lein-figwheel (1)
- # leiningen (2)
- # lumo (39)
- # nrepl (1)
- # off-topic (54)
- # onyx (124)
- # pedestal (1)
- # planck (4)
- # portkey (1)
- # re-frame (36)
- # reagent (2)
- # ring-swagger (8)
- # shadow-cljs (107)
- # spacemacs (1)
- # specter (25)
- # sql (7)
- # tools-deps (5)
- # vim (10)
- # yada (25)
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.
@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?
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.
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).
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.
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.
But you have to keep the file containing code from pack.alpha open source, but it's not "infectious" like GPL
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.
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!).
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
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.
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 🙂
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)
on the other hand, these task will be also callable straight from command line (like in your pack.alpha)