Fork me on GitHub

@xiongtx there's quite a few different things going on in that question, can you tease it out and tell us more about what it is you're actually trying to achieve?


I don't think there's any expectation that :provided dependencies are excluded from an uberjar, :provided is all about what shows up in the POM when the project is packaged as a library


@danielcompton but provided needs to prevent breakage in vms where some class is already loaded, even for an uberjar


I thought that was one of it's original uses


Yeah as a library


no, even in a container


@danielcompton Sure: I’ve a clj / cljs project that has some cljs deps. IIUC all those cljs deps will be compiled into a single JS file. It seems therefore that I don’t need those deps to be packaged in the Uberjar--all I should need is the compiled JS file.


like, your j2ee or tomcat or whatever provides it's version of some class which connects you to the server context


thus provided scope to ensure you don't ship it


hadn't thought about that case


@xiongtx I think I would have a :cljs profile which was included at dev time, and you would somehow run the clojurescript build when creating your uberjar


You're definitely not the first person to want something like this


So I think the :provided profile might actually be working. But the cljs files a la :output-dir are being put into resources/public/..., which is why they’re being copied into the JAR. > The :provided profile is used to specify dependencies that should be available during jar creation, but not propagated to other code that depends on your project. These are dependencies that the project assumes will be provided by whatever environment the jar is used in, but are needed during the development of the project.


Basically, from what I can see, there’s not reason to have any cljs / JS other than the final, compiled JS file in the Uberjar. That’s the goal.


> Please note that putting things in the :test profile is strongly advised against as it can result in tests which can’t be run from the repl. So the :test profile is officially deprecated, correct? Just put things in :dev instead?


I have a related question to the provided dependencies. I have a dependency I only need at compile time, to create java classes. But if I put it on provided, modules depending on it complain it's missing. Might be solved by having it provided in the parent, and excluded in de child? Or is clojure code always read, even when aot compiled. In which case the childs do need it?


From what I get from googling, the only proper way would be to make a leiningen plugin from it..


does putting it in the :dev profile not do what you want?


possibly, will try out tonight, it’s not a big problem, but I like dependencies to be as little as needed


Since the code for the creation is in a seperate namespece, I could even put it to a different source, only used with dev, that should work.


Does anyone here know how to lock a java -SNAPSHOT dependency to a specific timestamp build? I’m basically trying to lock against the current latest build of JENA (available in this repository: I’ve added

:repositories [["apache-dev" {:url ""
                                :releases false}]
:dependencies [[org.apache.jena/jena-arq "3.7.0-20180130.100450-16"]]
But it fails to resolve it


Could not find artifact org.apache.jena:jena-arq:jar:3.7.0-20180130.100450-16 in apache-dev ()


hmm ok if I do it in a new project it seems to work… looks like the profiles are stomping on each other or something


ahh its ok PBCAK


Say, I'm trying to use from a leiningen plugin but no output is forthcoming, either in a log or to the console. I have included log4j2 in the plugin dependencies, and just running my main function from the command-line works fine. Anyone have an idea?


I've got a big batchy job that I'm kicking off from the plugin, so I'd really like to log some stuff


you could double check the log level


It seems like it's kosher to me, but maybe I'll try manually lowering the global log level to be sure


you should use leiningen’s built-in logging facility


if this is really plugin-level logging


Well, the thing is I want to produce an output.log file for the user after the plugin is done


unless you’re expecting the user to change up the log level, it might be simplest just to spit strings to the file with a local function in your plugin