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.]
Related
I have a c++ project with a couple of executables set up with cmake. The usual workflow is to install all 3rdparty dependencies via package manager, build and install a package via cpack on that same machine. Now, I would like to include all runtime dependencies in that package to be able to install it on another machine without needing to install 3rdparty dependencies there like on the build machine.
I did lot's of research on the web - without much success. I found something called BundleUtilities for cmake but couldn't find any entry-friendly documentation about it. I don't even know if it does what I need.
I would like to use cmake's benefits and generate such a "bundled" package without any manual intervention or anything. I do not want to assemble and copy 3rdparty dependencies manually. Ideal would be a clean cmake/cpack solution for the problem.
Edit:
To clarify: The target machine in question has no internet connection.
Are you really sure you want to do this? It probably won't turn out to be a great idea... packaging third party tools is effectively assuming responsibility for third party software, and as the upstream version inevitably gets out ahead of what people are finding in your tarballs that can become a real headache. Consider whether you're really ok with seeing version conflicts because your dependencies are installed.
Why not just have cmake call out to the system's package manager at config time? The exec_process() command will run console commands for you.
I am learning Clojure and coming from a Ruby background.
I am looking for something analogous to gem install <library>. The various incantations of lein install do not seem to fit this bill.
Is there a way to simply install a library locally so that it can be referenced in the REPL without the need to create a project?
Seems like, you want to install a library with lein. Here is the plugin, install it and use like
lein localrepo install <filename> <[groupId/]artifactId> <version>
If your aim is merely to load libraries in the REPL consider using alembic. It loads dynamically classpaths, resolve dependencies and automatically pulls libraries from the repositories.
Here is a use case:
(require 'alembic.still)
(alembic.still/distill '[enlive "1.1.1"])
It simply requires you to add the following entry to your .lein/project.clj:
{:dev {:dependencies [[alembic "0.1.1"]]}}
See this answer.
Java and thus clojure do not generally have the the idea of globally installed libraries. You should always be creating a classpath with the minimal set of dependencies. You need somehow to specify and manage this classpath and the easiest way to do this is with leiningen, which requires a project.
leiningen automates the process of retrieving the remote libraries and placing them in your local repository which is somewhat analogous to gem install, but these libraries do not become automatically available to a REPL.
The easiest way to have a set of libraries always available is to have a 'scratch' project which you use for REPL experiments before starting a new project. It's not too much of an overhead.
In lein 2 you can update profiles.clj with package you want to install:
~\user\.lein\profiles.clj
With the first run of any project with lein, the local repo will be updated with what was incereased in profiles.clj.
Sometimes I just run lein deps without being in a project folder, this will update the local repo for you.
This way you can add any library to your project.clj or call it from repl and it will be extracted from local repo.
If you don’t have a project, you add your dependencies in your global lein user profile instead located at ~/.lein/profiles.clj.
The doc isn’t great for lein to be honest. So this part is confusing. But you edit that file as such:
{:user {:plugins [[lein-pprint "1.1.1"]]
:dependencies [[slamhound "1.3.1"]]}}
In the :plugins vector you add whatever global lein plugin you want to have. And in the :dependencies vector you add whatever library you want available globally.
Then anywhere you start a lein repl you’d have those dependencies available to you. And everywhere you run lein you’ll have the additional plugin features available to you.
If you use tools.deps instead of lein, aka, the clj command instead of the lein command. Then it is a bit different. You instead want to modify your ~/.clojure/deps.edn file. Where you’d add dependencies there instead:
{:deps {clj-time {:mvn/version "0.14.2"}}}
So if you put the above in your user deps.edn whenever you run clj command the clj-time library will be available to you.
Should I create a local repository to change the dependencies of a dependency in my project?
I have a clojure project that is using docjure. docjure contains a dependency on poi 3.6.
Because of a bug in generated Excel files I am reading, I have a local version of poi 3.8 that I hacked to workaround the bug.
It's easy enough to stick my poi 3.8 jars into my projects lib/ directory so that my project will run ok at the repl.
But, lein deps (or jar and uberjar) happily cleans the lib/ directory and reinstalls the 3.6 versions of poi, breaking my build.
I think the probable solution is two-fold:
1 - put my hacked poi 3.8 into a local repository
2 - create my own local copy of docjure and update it's dependencies to point to that local repository.
I am looking for confirmation that this is the "right thing" to do in this case or someone to point out that it is much easier to just do something else.
It is worth reading Leiningen's Repeatability wiki page if you haven't already. To quote part of it:
If the code is public, you should open a bug report with upstream to get them to publish it in a public repository like Clojars, Sonatype, or Maven Central, depending on the project. If they are resistant or too slow it's always possible to publish "Clojars forks"; see lein help deploying for further details there.
The ultimate solution is to try and get your changes pushed upstream. Then you can depend on the version you need, and I think Leiningen will prefer that version if it's higher than the transitive version.
Another option might be to include your jar in a safe (checked-in) directory. Then write a plugin that can hook into a built-in task and copy the jar to your lib directory for you. I really don't know if this will be successful, but it's worth looking into.
I have been able to run a custom plugin from within my projects project.clj, and even leiningen/plugin.clj (ie just a private plugin) - but when I go to put this plugin in its own project - I am unable to get it to work at all.
Following the advice, I should create a new project, and have a namespace of leiningen.myplugin etc etc... but the jar that I produce doesn't seem to provide the new task in the project (either via jar, or via clojars).
http://nakkaya.com/2010/02/25/writing-leiningen-plugins-101/
https://github.com/technomancy/leiningen/blob/stable/doc/PLUGINS.md
Anyone who has published a plugin care to confirm if the above is correct - or is there some crucial step I am missing? (I assume my task goes in core.clj in the plugin project)
Do you have the :eval-in-leiningen option set to true in the project.clj?
In addition if you want to use the task all around with your leiningen without having to add it to the dev dependencies of the project where you need to use it you need to use lein plugin install
Or did i miss something about your problem
Note that eval-in-leiningen doesn't need to be used for very simple project-specific plugins or tasks, and it can sometimes wreak build havoc. You can enable a Leiningen task for a given project by just using .lein-classpath for that project. More information here:
Project-level Leiningen Plugin
I'm new to Clojure but I'm learning it. I'd like to know the best way to package and distribute a Clojure program to end users who aren't necessarily programmers. I know in Ruby you can just tell users to download the program with gem install [program name] and then run the command that runs the program. What's the equivalent for Clojure programs?
I you use Leiningen it has an uberjar command to make self contained executable jar files, which your users can just double click. See: http://zef.me/2470/building-clojure-projects-with-leiningen
Clojars is great if you're distributing a library, but I'm not sure if that's the best option for end users.
If you're already using Maven, I believe the best option is to create a uberjar containing all required classes. If you want to make it even more end user friendly, you can then create an installer from this jar using something like IzPack. Just remember that Clojure programs are Java programs, so all distribution options for Java are valid for Clojure as well.
lein uberjar works great for small mostly-Clojure apps, but it doesn't scale when using many Java libraries, including necessary licenses, and other such things. If you use the Maven Clojure plugin, you could take advantage of the vast and terrifying Maven assembly plugin to build and final structure you might conceivably need.
Or you could write a Leiningen plugin to do something similar. I'm not sure if such a thing exists.
Clojars (http://clojars.org/) is the bigger repository of Clojure libraries you can find.
It works perfectly with Leiningen projects or any other Maven based project management tool.