Moving my project from Ant to Leiningen went so smoothly that I am looking at new things to include in the build process. one of which would be to automatically create a .deb and .rpm file in the build. What is the easiest way to do this?
I think your best bet would be to write your own Leiningen plugin for this (which I hear is pretty easy), or use the lein-scripts plugin and write a script/task for it.
It would be really great to have a lein plugin to help with this. Since it already uses maven under the hood, you could look into using the maven-unix-plugin (http://mojo.codehaus.org/unix/) which can build .deb and .rpm files. Otherwise if that looks annoying I don't think either package format is especially complex. You could probably do it by hand in Clojure, in which case maybe looking at some example Ruby Rake tasks would help. (http://rubyforge.org/projects/pallet/)
I've come across the same problem. I followed rosejn's suggestion and created a Leiningen plugin that uses the RPM Maven Plugin to create an RPM. I've put it here.
Related
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.]
I have found a problem with the test environment in a c++ problem.
We have a machine which downloads the code from the version control system and, build it and execute the unit test, nothing new.
The problem arise when we add a new dependency in our project. We are developing a lot of features at the same time and it is something relatively common. We this happens we have to advise testers and give them an easy way to reproduce the compilation environment ...
And I was thinking if there is any other easy way to go through this ... don't know, some tool like virtualenv or buildout for python ..
I have been searching at google, but with no luck.
Any help will be appreciated.
You can always add all of the dependencies to the revision control system and provide automated scripts that will install the required subsystems. Where I work, if you just download the current version from the repository, you can build in one step an ISO image that can be installed by testers in any computer they want. The image contains everything from the OS up to the application.
Depending on your particular situation, you might want to start with smaller steps, like adding the dependencies to the repository and having the testers check there whether any new file appears or changes version.
No ready tool, AFAIK, except maybe for CMake which can control things like that for you.
For C++, it's fairly easy to manage "by hand" since you can set LIB, LIBPATH and PATH environment variables to carefully selected directories. No site.py, eggs, .pth files and the like as with Python.
We do this at our shop, setting up our build/development environment closely and have everything in revision control (mostly scripts that download huge zips of prebuilt libs and unpack them to the right places).
Small libs are copied to common dirs, larger get their own entry in the env-vars.
This works equally well for Python and Java. Haven't tried other languages...yet. :)
Is there a simple way to find out what versions of dependencies are available using Leiningen?
E.g., if I have a web app which depends on Hiccup and Compojure, how can I be sure that I'm on the latest version of each without going to the github page for each?
NOTE: I use Ant and Ivy for building my Java projects, so I have limited knowledge of Maven - so please spell out (or provide Fine Links for me to read) any Maven concepts that Leiningen exposes to me which would help with this (I know that under the hood, Leiningen uses Maven for dependency resolution). Ta.
The Clojure ecosystem has evolved since the original answer was offered. At the present time, I would recommend using lein-ancient:
A Leiningen plugin to check your project for outdated dependencies and plugins. This plugin supersedes lein-outdated and uses metadata XML files in the different Maven repositories instead of a Lucene-based search index. Version comparison is done using version-clj.
Its precursor, lein-outdated, has this helpful message in its README: "lein-outdated is outdated". :)
The canonical way of doing this, at least for dependencies kept in clojars, is the lein-search plugin.
Update: See the highest-rated answer below for a more up-to-date response.
You should have a look at the answer to this question. Leiningen uses the same versioning mechanism as maven so, for example, if you want to use the latest version of a given library, you can substitute the word "LATEST" for the version number. You can also specify a release version or a version range. Again, look at the answer at that link.
Web service that provides this info, along with badges for readmes.
http://clj-deps.herokuapp.com
Disclaimer, by me.
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.
What we need in our firm is a sort of release management tool for Linux/C++. Our products consist of multiple libraries and config files. Here I will list the basic features we want such system to have:
Ability to track dependencies, easily increase major versions of libraries whose dependencies got their major version increased. It should build some sort of dependency graph internally so it can know who is affected by an update.
Know how to build the products it handle. Either a specific build file or even better - ability to read and understand makefiles.
Work with SVN so it can check for new releases from there and does the build.
Generate some installers - in rpm or tar.gz format. For that purpose it should be able to understand the rpm spec file format.
Currently we are working on such tool which is already pretty usable. However I believe that our task is not unique and there should be some tool out there which does the job.
You should look into using a mix between Hudson, Maven (for build management), Ivy (for dependencies management) and Archiva (for artifacts archival).
Also, if you are looking into cross.compilation, take a look at Make Project Creator (MPC) and Bakefile.
Have fun!!
In the project I'm currently working on we use cmake and other Kitware tools to handle most of this issues for native code (C++). Answering point by point:
The cmake scripts handle the dependencies for our different projects. We have a dependency graph but I don't know if is a home-made script or it is a functionality that cmake provides.
Well cmake generates the makefiles regarding the platform. I generates projects for eclipse cdt and visual studio if it is asked to do so in case of developing.
Cmake has a couple of tools, ctest and cdash that we use to do the daily build and see how the test are doing.
In order to create the installer cmake has cpack. From just one script it can generate tar.gz, deb or rpm files in Linux or an automatically generated NSIS script to generate installers in windows.
For Java code we use maven and hudson that have been already mentioned here.
Take a look at this article from DDJ, in which a more robust build system concept (than make) is presented and implemented. Not sure it will fit well to your requirements, but it's the closest I've ever seen. I was looking for the same thing months ago, and then I discovered the article.
http://www.drdobbs.com/architect/218400678
Maven has a native code plugin. I don't think it'll do everything you want, but it's good at tracking version numbers of dependencies, will build artefacts and it'll work with your VCS.
No idea
cmake/scons: I have used cmake but I don't exactly love it, but I have heard really good things about scons. But scons is python-based, so you need to have python installed on the build/dev machines.
I use Hudson, which has a plugin to fetch from svn. It performs intelligently in general, and in particular builds only if some file has changed in an svn update. Hudson is easy to get started with. Hudson is java-based and is pretty popular with the Java community. This means it is quite cross-platform, but you need to have JRE installed on the build machine.
Probably can call some rpm tool within hudson.