What does :scope "provided" mean? - clojure

I've seen a lot of places where some dependencies in Clojure project are marked with :scope "provided" (example).
What does it mean?

This is essentially a maven concept. Provided means that the given dependency is already packaged(or "provided" if you will) with the environment. The jar is necessary for compiling but it won't be packaged with the app. Also these are not transitive dependencies.
To understand more about transitive dependency refer here.

You can read about maven scopes, since it is the same thing. Difference between maven scope compile and provided for JAR packaging . So as far as i can understand, if you use this lib in your project, you should also add these dependencies to your project.clj, together with the lib itself (still i can be mistaken)
There are also some other scopes you can use: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Related

How to find not used dependencies in Bazel build file?

Suppose I've a Bazel package with a BUILD.bazel file that contains a list of dependencies. Some dependencies are not in use anymore. How to find the dependencie that are not in use ?
This is a Java project but I think the language is not important.
unused_deps works for Java projects. There is no tool that works for all languages. For C++ a pattern like IWYU can help to decide when and how to make a dependency.

In a Clojure/ClojureScript project, what are the advantages of declaring dependencies on a `deps.edn` file instead of using `shadow-cljs.edn`?

I have been using Clojure, ClojureScript, lein, shadow-cljs, re-frame, reagent, Emacs, and CIDER to work on a Clojure/ClojureScript dynamic web app project.
Currently, the project uses project.clj and shadow-cljs.edn to declare dependencies.
There is a discussion about changing things so that:
1 - We would start using a lein plug-in called lein-tools-deps
2 - Also, we would tweak shadow-cljs.edn file so that the dependencies would be removed and the file only indicate:
:dependencies true
3 - Finally, we would create a new deps.edn file holding all the dependencies.
It is not totally clear the advantages of this process.
I can see one: instead of declaring dependencies on shadow-cljs.edn and on project.clj they would be in a single file: deps.edn.
Is there another benefit of having dependency declaration via deps.edn instead of using shadow-cljs.edn and project.clj via :dependencies?
For instance, would this affect the use of Maven packages hosted on GitHub packages? Is deps.edn better for that?
deps.edn has the benefit that it supports direct git dependencies (ie. :git/url), as well as an easy mechanism for local dependencies (ie. :local/root). It is also more modern and becoming the "default".
shadow-cljs.edn has no support for these features, project.clj has some via plugins or other mechanism (eg. checkouts).
So, if you want those features it make sense to use deps.edn. However, depending on how complex your project is that might not be an easy switch.
shadow-cljs ultimately doesn't care how you manage your dependencies, but if you move things out of shadow-cljs.edn you are taking "power" away from it. If managed via shadow-cljs.edn it tries to prevent certain mistakes (eg. dependency conflicts), it can't do that when running via deps.edn. So, you'll have to sort those out manually potentially. It may just work, really depends on your project.

Collaboration in a project with dependencies

I'm a DevOps engineer creating CI processes for projects. I was wondering what is the best way to deal with the following scenario: Let's say I have a C++ project (using CLion + CMake) with several developers working on it. Now in order to be built, the project has some libraries it depends on. That automatically reflects on the CMakeLists.txt file that should know where to look for those libraries.
Basically the problem is that we need to take care that every developer has these libraries in the correct paths on his machine, which is a big hassle.
One approach to handle this would be to keep those dependencies in the repository. That's great since all the developer has to do is to clone the repo and he got everything he needs in order to run compilation. But as we know, keeping binaries in SCM is not a good practice.
The question is, is there a good method to handle project dependencies in a C++ project?
I know that with C# for example, we could use NuGet packages to handle these kind of scenarios. So we'd have a NuGet repository in Artifactory that would host the dependency packages, and then in our project we'd keep a reference to the required packages, and in build time we would just download the dependecies and build the project.
Is there something alike in C++ (Running on Linux I mean)?
Hope the question is clear enough lol, had a hard time wording it..
It depends on how those dependencies are delivered and packaged. If whoever maintains your dependencies took CMake into account you can probably use find_package. If they didn't account for this, but they support pkg-config you can use FindPkgConfig. Now all you need to do is let the developers know what dependencies they need to install. This should work regardless of the OS used for development.
Other solutions may involve pulling and building the dependency code when you build your project (for example, by using git submodules if possible, or FetchContent, but this can become a nightmare if you have a lot of dependencies).
Additionally, you can try using a package manager like vcpkg, or conan (if all your dependencies are available there), or CPM.

Using a parent directory as a Leiningen dependency?

I am working on a Clojure library. Inside the library is an example app that shows how to use the library. In the example app, which is in a subdirectory, what is the cleanest way to depend on the parent library? I want this to be fast; I want the dependency always be in step with the current library code. That means avoiding deploying to Clojars (or elsewhere).
Use Leiningen "Checkout" Dependencies.
You can add "../src" to the :source-paths in project.clj
Since you always want the current version of the parent's code, and it will always be in the same relative place, it's less a "dependency" to be resolved and more a classpath to be used to find code.

Clojure, Lein, JavaFx, native deps

Context
I want to use JavaFx with clojure.
I am aware of http://nailthatbug.net/2011/06/clojure-javafx-2-0-simple-app/
Question:
Is there a way to make JavaFX work with Clojure using native-deps in lein instead?
Thanks!
I've created a simple Clojure and JavaFX example on Github. Testing on Ubuntu I had to install the JavaFX runtime into my local Maven repository, using the deploy:deploy-file target (install:install-file did not work for me).
mvn deploy:deploy-file -DgroupId=local.oracle -DartifactId=javafxrt -Dversion=2.2.0 -Dpackaging=jar -Dfile=/usr/lib/jvm/java-7-oracle-amd64/jre/lib/jfxrt.jar -Durl=file:/home/raju/.m2/repository
Make sure you have the following arguments set correctly:
-Dfile={full path to jfxrt.jar in jre/lib folder}
-Durl=file:{full path to Maven repository, e.g. $HOME/m2.repository}
In the project.clj, I added the dependency based on the -DgroupId and -DartifactId values when installing the JAR into the repository. If you use change these values, make sure to change the dependency accordingly:
[local.oracle/javafxrt "2.2.0"]
Java was able to load the binary libraries without any problems. If Java reports problems loading a binary library, e.g.
Caused by: java.lang.UnsatisfiedLinkError: Can't load library:
/usr/lib/jvm/javafx-sdk/rt/lib/amd64/libglass.so
check out these two question on SO:
What is LD_LIBRARY_PATH and how to use it?
java.lang.UnsatisfiedLinkError no *****.dll in java.library.path
Because JavaFx has native dependencies your option are limited to, ]
shipping these dependencies with your project (including them),
creating a package that you can depend on which has them (providing them),
or having your package require the user to install them in some other way.
Because the tutorial you link to covers the case where the user of your package/program installs JavaFx on their own, by using robert.hook and depending on the end-user's package manager to provide the actual native dependencies. I'll cover how to have your package/program include the dependencies.
native-deps can be used to ship native dependencies with your package. You just need to add all the .so, .dll, .etc files in the appropriate directories. I think the projects github page does a better job than I of explaining the structure.
The link in the question is broken so I can't see your example, but with Java 8, JavaFX is now part of the standard JDK/JRE. I therefore expect the native dependency issue to be irrelevant at this point.
Not sure if this will work for others, but this appears (so far) to have worked for me:
mvn install:install-file -DgroupId=javafx -DartifactId=javafx -Dversion=2.1.0 -Dpackaging=jar -Dfile=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/jfxrt.jar
I have no idea why this works, but I believe jfxrt.jar has the files I need. Then, after this, I kindle it in project.clj as
[javafx "2.1.0"]
in the :dependencies (not :native-deps) section.
[Having written this, I really have no idea why this even appears to work.]