When using leiningen to build Clojure applications, how can certain dependencies be excluded from being included in the JAR file when using lein uberjar?
Use the provided entry for the leiningen profile.
:profiles {:dev {:dependencies [[ring-mock "0.1.5"]
[prismatic/dommy "0.1.3"]
[org.bouncycastle/bcprov-jdk15on "1.50"]]}
:provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]}}
One common use case is bouncycastle that needs to be excluded from the signed JAR and provided externally using its own jar file in runtime.
Similar to what Guillermo suggested modify your project's :profiles to include something along the lines of:
:provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]
[org.bouncycastle/bcpg-jdk15on "1.50"]]}
(The specific versions may vary.)
Trouble is that if you use a Clojure wrapper library (such as clj-pgp or thi.ng/crypto), it forces inclusion of the jar in the uberjar, breaking the process.
My solution was to fork the library and push it to clojars after modifying its project.clj to uses provided dependencies.
More details here: http://side-effects-bang.blogspot.com/2015/02/deploying-uberjars-that-use-bouncy.html
In the project.clj under :dependencies you can add exclusions for specific jars like this:
[test/test-jar "1.0" :exclusions [sample-exclusion/test-exclusions]]
Related
I have a simple sbt application that uses typesafe-config library and is build using sbt-native-packager.
I build it using following command:
sbt universal:packageBin
Within the src directory I have following hierarchy:
main/resources/application.conf
test/resources/application.conf
staging/resources/application.conf
And my archive always ends up containing only the main version of application.conf
I'm looking for a easy way to include specific application.conf file based on for example java property passed during project build, but I'm unable to find anything.
Have you taken a look at the mappings facility, which allows you to add/remove files from the base layout? See Change-Remove Top Level Directory In Output in the official docs.
I have written custom clojure functions that I want to use in my riemann configuration. I am using leiningen to build jar file (with dependencies) containing my functions. What is the right way to include this jar file in the classpath when starting riemann ?
I have only found this way. I'm not sure whether this is the right way :
java -cp "/path/to/my/custom.jar:/path/to/riemann-0.2.6/lib/riemann.jar" riemann.bin /path/to/riemann-0.2.6/etc/riemann.config
I am trying to build a Sailfish OS app, and I need to use *.wav files, which are to be distributed through the *.rpm package. In my case, these files are to be put in /usr/share/[application_name]/sounds/*. How do I set up the *.pro and *.yamp files accordingly?
This isn't a RPM question per se: you seem to be asking how to configure
your application through *.pro and *.yamp if you deliver content in
*.rpm packages.
The packaging answer is: Patch the configuration files exactly the same
as if you were installing the *.wav files manually (i.e. not through *.rpm).
You will need to copy the *.wav content into the %buildroot tree that
is used to stage the files to be included in the package, as well as the
modified *.pro and *.yamp content. All the files to be included in the
*.rpm package will need to be mentioned in the %files manifest exactly
as they are to be installed (i.e. w/o the %buildroot prefix used for
staging files while building).
I finally found an answer!
I want to thank to the owner of that project:
https://github.com/krig/metronom-sailfish
From the .pro and the .yaml files of this project i found out how to deploy the files. First, we declare that constant:DEPLOYMENT_PATH = /usr/share/$${TARGET} which seems to hold the path to /usr/share/[appname]. Next, we define some kind of a variable (TODO: find a more detailed explanation of that). The definition of that first sets the path to the files, for example, data.files = data (the second data is the folder). Next, we set data.path to $${DEPLOYMENT_PATH}. We list all the files in OTHER_FILES and add the setting, in our case, data, to INSTALLS. Now, that we are finished with the .pro file, we move to the .yaml file for the .rpm and we add to the necessary line to the Files: section, in our case, - '%{_datadir}/%{name}/data', the last being the folder we need to add. TODO: to whoever is more experienced, please provide a more detailed answer.
Did you check https://sailfishos.org/develop-packaging-apps.html carefully? May helps.
I am working with sbt-thrift plugin 0.6 and SBT 0.12.
In my thrift files I have mentioned the namespace as below.
namespace java abc.xyz
//some
//thrift
//codes
But the generated files goes to
gen-java/abc/xyz
(gen-java prefix is added automatically). How can I change this into
abc/xyz
?
There is an -out <outdir> option which does exactly that. In your case, specify the current folder . as the outdir.
Note that, unlike with the automatically generated gen-* folders, the outdir directory must exist. In other words, you have to make sure the folder is created before calling the Thrift compiler.
The --help option gives more information about all the other switches.
Regarding SBT, if the information on https://github.com/bigtoast/sbt-thrift is true, then you should contact the author of that software to add the option thriftJavaOutputDir as it seems missing.
BTW, the question looks very much like a duplicate of How to change default settings of sbt-thrift plugin in SBT? I would recommend to NOT ask ten thousand copies of similar questions on SO.
I created simple Java Servlet: WelcomeServlet.java.
Than, I tried compile this file via:
javac WelcomeServlet.java
In result I see compile error:
package javax.servlet doesn't exit
I try find solution for this error with Google. And I find first part of answer: java compiler doesnt see servlet-api.jar file.
I know, that Apache Tomcat in it lib folder contains servlet-api.jar file.
So, I have this file, but where I must copy this file??
I try different folders:
echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_26
%PATH% contains this line: C:\Program Files\Java\jdk1.6.0_26\bin
So, I copy in:
%JAVA_HOME%\bin
%JAVA_HOME%\lib
%JAVA_HOME%\jre\lib
And in result same error.
And only after I copy servlet-api.jar in directory:
%JAVA_HOME%\jre\lib\ext
compilation complite sucessful.
My question: Why? Why I must copy in folder %JAVA_HOME%\jre\lib\ext ??
Where This moment describe in documentation?
And other question we have some official docs or specifications that describe folder structure for jdk folder??
You'll need to specify the directory or directories you want the compiler to search by using the -classpath command line option when running javac. The reason the compiler found your .jar in %JAVA_HOME%\jre\lib\ext is because it searches the extension directories by default.
This is for Java 1.5, but I believe it is more or less still correct:
http://docs.oracle.com/javase/1.5.0/docs/tooldocs/findingclasses.html
The link Shaun provides is a more complete answer. But in short, using the classpath is the best way to introduce 3rd party or external (to the JDK/JRE) libraries. The classpath is a concept much like the %PATH% or the $PATH variables, but specifies locations for java to use for lookup rather than the shell to use for lookup of executables.
The classpath provides the java compiler or java virtual machine a list of items to use when searching for resources. This "path" may include directories or files. It will typically include jar files and sometimes locations of configuration files. Many Java based lookup schemes for files configuration or otherwise use some variant of what is accomplished by [Class#getResourceAsStream()][1]'s use of walking the Classpath.
I have rarely seen an incident where putting a jar file in the lib/ext location was preferred to utilizing the Classpath.
The classpath is typically an environment variable (%CLASSPATH% or $CLASSPATH) or specified on the command line when running java or javac (e.g. -cp or -classpath see the help from the executable you are running).
Build tools such as Ant and Maven will also provide abstractions to defining the list of jars to be utilized by your applications and are highly recommended to be used for any length of repetitive change code, build, test, run cycles.