Is there a way to get Gradle to NOT compress the files when using the "jar" task?
I can't for the life of me find any reference to setting the compression settings for a jar.
This may only be in the newer version of gradle, but you can now specify entryCompression for your jar task:
ZipEntryCompression entryCompression
The compression level of the entries of the archive. If set to ZipEntryCompression.DEFLATED (the default), each entry is compressed using the DEFLATE algorithm. If set to ZipEntryCompression.STORED the entries of the archive are left uncompressed.
Gradle's Jar task doesn't currently support any compression options. To generate an uncompressed Jar, use the Ant task.
Related
I have a project that is using spring boot and when is build it generates a jar containing all dependencies jars.
I want to obfuscate this jar, but after obfuscation when I try to run the jar I get:
java.lang.IllegalStateException: Unable to open nested entry 'lib/h2-1.4.185.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file
at org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:378)
at org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:355)
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:341)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:108)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:92)
at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:74)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:60)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:45)
I tried to find what is the issue and for that I create a config file only with:
-injars MyJar-orig.jar
-outjars MyJar.jar
-libraryjars <java.home>/lib/jce.jar
-libraryjars <java.home>/lib/rt.jar(java/**,javax/**)
-libraryjars '..\..\resources\proguard5.0\references\log4j-1.2.17.jar'
-dontobfuscate
-dontshrink
-dontoptimize
I was expected to get the original jar, but I am getting a jar that is smaller and all the classes have different size (smaller in general).
What is proguard doing in this case?
Any idea how I can solve my issue?
please have a look at the '-keepattributes' parameter. When using the Proguard GUI, under the 'Obfuscation' tab there is an option for this. Clicking this solved my problem which was similar/ the same as yours.
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]]
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.
My company uses .zip sources for some of its libraries. Is there any way for me to tell sbt to search for .zip extension as well as .jar?
I've tried specifying the artifact dependency explicitly through an artifacts(Artifact(...)) call, but that makes the sources required, as opposed to optional the way jar ones are.
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.