Clojurians
#leiningen
<
2018-01-30
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

danielcompton01:01:59

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

danielcompton01:01:50

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

noisesmith01:01:56

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

noisesmith01:01:03

I thought that was one of it's original uses

danielcompton01:01:12

Yeah as a library

noisesmith01:01:20

no, even in a container

xiongtx01:01:30

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

noisesmith01:01:54

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

noisesmith02:01:07

thus provided scope to ensure you don't ship it

danielcompton02:01:21

hadn't thought about that case

danielcompton02:01:28

@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

danielcompton02:01:46

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

xiongtx02:01:42

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. https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md#default-profiles

xiongtx02:01:28

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.

xiongtx03:01:54

> 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? https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md#task-specific-profiles

gklijs04:01:55

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?

gklijs05:01:58

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

greg31605:01:49

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

gklijs09:01:09

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

gklijs09:01:20

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.

rickmoynihan16:01:38

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: https://repository.apache.org/content/repositories/snapshots/org/apache/jena/jena-arq/3.7.0-SNAPSHOT/ I’ve added

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

rickmoynihan16:01:14

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

rickmoynihan16:01:08

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

rickmoynihan17:01:50

ahh its ok PBCAK

timgilbert22:01:35

Say, I'm trying to use clojure.tools.logging 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?

timgilbert22:01:03

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

noisesmith22:01:34

you could double check the log level

timgilbert23:01:24

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

greg31623:01:29

you should use leiningen’s built-in logging facility

greg31623:01:40

if this is really plugin-level logging

timgilbert23:01:02

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

greg31623:01:12

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