Fork me on GitHub

Morning from Vietnam! 🙂


@mikerod I just noticed it seems no one’s using it these days. I don’t plan for us to do anything special to drop support for Java 7, we’ll likely just remove it from the build matrix once we ship out CIDER 0.17, which should happen at the end of the month / beginning of next month if everything goes well.


Midnight greetings from San Francisco, does CIDER make any attempt to expose it’s “pick the machinery with which to start an nREPL” server logic to other systems like say vim-fireplace?


@arrdem I don't understand the question, but as a vim user, I can probably answer.


@dominicm I think the answer is no - the emacs CIDER client has a bunch of smarts which figure out how to run a CIDER repl using deps.edn or boot or lein or what have you.


yeah, that's too early for it to be shared. The shared area is in the nrepl. Fortunately the logic isn't too complex, and was replicated in


vim-jack-in had deps.edn jack-in before cider infact.


My question was whether that logic is (or could be) packaged outside of emacs such that fireplace or other tools could use it too, specifically because I’m toying with writing a new build tool which would need its own incantation support.


And it’d be really neat of that could be fully shared etc.


Thanks, I’ll keep that in mind. I suspect I’m gonna try to build an MVP atop lein and see how that goes, which makes this a non-need for now.


The only thing your build tool needs to expose is a way to add deps & maybe middleware, from the cli. But having eval works too.


Yeah, you can’t really share this, because all of this happens before booting the server.


Unless you package it as a Python script or something. 🙂


I’m considering to drop the Gradle support from CIDER. Seeing the usage results it seems that just 2% are using it With Gradle we’re not doing deps injection, as with everything else, and it seems no one is particularly interested to make things there better, so I’d rather just kill the limited support we have for it simplicity/consistency. Any objections.?


(that support extends just to cider-jack-in)


what's the cost of keeping it?


I don’t use gradle myself, but 2% is still a few people. Could it be a separate module, so that those 2% can try to keep up themselves?


@dominicm The cost is not high, but it doesn’t work like everything else, therefore my preference is not to have it at all (I dislike inconsistent features). Obviously gradle users can simply start the server manually in this situation and connect to it.


> I don’t use gradle myself, but 2% is still a few people. Could it be a separate module, so that those 2% can try to keep up themselves? The support for gradle is just project detection, a few configuration variables and dispatch on the project type here and there. Extracting something so simple seems like an overkill, as it would complicate the existing code.


Just for the protocol - if deps injection is possible with Gradle and someone wants to work on it, I’d be fine with keeping it.


I find 2% surprising. I wonder how many of those represent people who actually use clojure and gradle together on a regular basis


As opposed to people who have at some time used gradle and clojure or who use gradle and use clojure together. I think a lot of people don’t answer these kinds of things honestly, especially on the fringes.


Perhaps. Frankly I’m more surprised about the Maven usage, but I guess those are some mixed Java/Clojure projects.


People using maven are less likely to use slack, and less likely to attend conferences I suspect. Enterprise is a silent market for clojure.