I'm using Apache Maven to release our product to Production, and as of right now, the resultant jar file that is created does not have a version number appended to it. I would like to append the current pom.xml version number (which I know how to do), but I need our installer script (basically a java -jar command with extra parameters) to access the newest version of the installer by default.
Say my deployment file is called foo.jar. My script is basically java -jar foo.jar
Instead, I'd like my deployment directory to contain foo-4.0.0.jar, foo-4.0.1.jar, foo-4.0.2.jar, etc.
I would like to create a bash script that runs the highest version of foo.
I've looked at sorting by creation date, but I can immediately think of scenarios that might not work out very well. I've considered doing it by date modified, and then manually touching the file that I want to install, but that idea kind of sucks too.
Clearly I need to split the name (probably with a regex) and isolate the version numbers (maybe substring from the last dash and the last period in the name?) and somehow sort them. The sorting is probably my biggest concern...that and reassociating the file.
If this is too complicated, I could theoretically make a Java file that does this (has it become clear that my primary language is Java?), but ideally it would just be a bash script.
Thanks
You can use sort, specifying the separator and set of keys to sort on e.g.
$ ls *.jar | sort -t- -k2 -V -r
will sort your jars in reverse (-r) using a version number (-V) sort, separating the version number from the jar name using -t-, and sorting on the second field using -k2 (your version number)
In my test directory I get:
a-2.2
a-2.1
a-2.0
a-1.50
a-1.10
a-1.3.1
c-1.3.0.1
a-1.3
a-1.2.9
b-1.2.8
a-1.2
which looks good.
Pipe the above through head -1 to give you the top entry.
Bash launcher script
Note: Verbose command options are used to make the script more reusable and easier to maintain.
#!/usr/bin/env bash
java -jar $(ls /home/opt/deployment_dir/*.jar \
|sort --version-sort --field-separator=- --key=2 --reverse \
|head --lines=1 \
)
Beware: Both the .jar file and above bash script should be rendered executable using the chmod +x command.
Related
I am trying to run a Java application which has many dependencies. In the past I have use the following command to launch the application
java -cp "program.jar:jar1.jar:jar2.jar:jar3.jar:[...]" program
However as the list of dependencies have grown, I have moved them into an arguments file, the contents of this file are:
-cp "\
program.jar:\
jar1.jar:\
jar2.jar:\
jar3.jar:\
[...]"
And I am running the application with
java #arguments-file program
Everything up to this point works fine.
Sometimes I end up with beta versions of program.jar, they share all of the same dependencies, but program.jar is renamed program-beta.jar.
So to run the jar the following command would be used
java -cp "program-beta.jar:jar1.jar:jar2.jar:jar3.jar:[...]" program
or more specifically, I would use an environment variable, so that the same script can be used, and the variable would be set to either program.jar, or program-beta.jar, depending on the circumstance
java -cp "$PROGRAM_JAR:jar1.jar:jar2.jar:jar3.jar:[...]" program
Now that I am using an arguments file I was hoping to be able to be able to do something like:
java -cp "$PROGRAM_JAR" #arguments-file program
However using -cp twice causes one of the two to be ignored, resulting in a java.lang.ClassNotFoundException exception.
Is there any way around this that allows me to specify one jar file by name, but abstract away all of the others so that my java command isn't thousands of characters?
This will be running entirely on Linux, so any command line "magic", such as using grep is fine, so long as the resulting code is easily readable
You could just write two bash scripts production.sh and beta.sh that contain a reference on program.jar and program-beta.jar, respectively.
Also, the classpath can contain wildcards (see man-page), so if you can ensure that on disk exists only one of the two versions, you can write it like this:
java -cp "program*:jar1.jar:jar2.jar:jar3.jar:[...]"
In the long term, you might think about building/running it with Maven or Gradle, depending on your requirements.
I have a program which allows me to define the java executable (/usr/bin/java), but does not allow me to add specific arguments to the executable.
I want to be able to run Java with a specific argument each time in order to enable Security Manager.
So far, I have tried to add the argument after /usr/bin/java, so it looks like
java=/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy
That did not work as the program probably checks to see if a file exists. Another way I tried was to make a bash script called java which contained:
/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy $*
I then set the java path to /home/java (Location of my script). That however did not work either. Is there some sort of way I can do this?
Thanks.
Put your java call in a shell script java.sh:
#!/bin/bash
/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy $#
Change permissions with chmod u+x java.sh, then call your program with java=./java.sh (adapt path for your script as needed).
Notes about executable bit and shebang line
Both the shebang line (#!/bin/bash) and execute permission are important here. Without them, system calls of the exec* family will fail because the kernel does not know what to do with the file or because execution is rejected due to the missing executable bit.
This is different when run directly from a shell (./java.sh), because most shells have some compatibility feature for that case so they will run a script in a shell if exec* fails. The execute permission must be set though.
The only case where neither is needed is if you give your script as argument to the shell: bash java.sh.
Your second approach would be ok, but your problem is likely to be that your Multicraft application is not finding your script. More so, it's the environment of your web server (Apache?) that may need to have PATH altered to be able to find your java wrapper script.
I have created one java program on my Linux system which indents and formats the given file. I want to make that program work like a command in Linux which will take file names and other options as arguments and then will produce the output. I can do this with a C program by just copying the compiled executable in /bin folder but I don't know how to do it with java.
Sample script that can might further help-
#!/bin/bash
#Set whatever number of arguments you expect for the Java jar you have
ARGS_EXPECTED=3
if [ $# -ne $ARGS_EXPECTED ]
then
echo "[$HOSTNAME]: Usage: `basename $0` filename arg1 arg2"
exit 1
fi
java -cp yourfile.jar com.yourpkg.Driver $1 $2 $3
Save the above content to a file, say test.sh
and use the command to give an executable permission chmod +x test.sh
run like ./test.sh filename arg1 arg2 from current directory where test.sh is
I thing this can be useful for your case: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/binfmt_misc.txt?id=HEAD
You can simply run a Java class file or jar file with "java" command from command line. Example:
java -jar yourprogram.jar argument1 argument2
If you save this line in a text file saved for example as "script.sh" and then give it the permission for execution you can run it double clicking or from terminal typing ./script.sh in the same folder containing the file script.sh.
You can also produce scripts that use arguments with $1 $2 etc. avoiding the need of editing file.
http://www.linuxquestions.org/questions/linux-newbie-8/how-to-pass-command-line-parameter-to-shell-script-254396/
You can use named parameters, too.
You can also produce a C program for a new command like you suggested that run the "java" command. In this case you can introduce arguments directly from terminal and pass them to java command in the C source.
As others have pointed out it is probably best to use a small shell script to run the Java application. There are several open source products that will help you wrap your Java code to produce a runnable (set of) .jar(s).
If you have correctly separated your business logic from your interface (as you should) then it is probably best if your Java application parses the parameters given on the command line interface. To do this create a separate class for parsing such parameters and calling the classes making up the business logic. Of course this will lead quickly - if not immediately - in writing a parser for Linux like CLI parameters. When this happens you may wish to consider the Apache Commons CLI project.
If you don't want to use any wrapping application/runtime, my method is generally pointing to all the class file containers in the classpath and directly pointing to the class containing the static main method:
java -cp "path_to_jar;path_to_class_folder;etc" "nl.owlstead.stackoverflow.LinuxMain"
We are executing standalone java program from shell script, having a comman script to mention classpath, path, etc..In this common script, we have added several classpaths now and number of character is more than 9000.
It is working fine in the test env. Will it cause any issue in Production? Any limitation is there in linux to set classpath? What is the max char for command line inputs...
No, there is no limitation. In Windows there is (8191 characters), but not under Linux. We work with the concept of classpath-files. These file lists all the dependencies for the application, eg:
...
libs/org/easymock/easymock/2.2/easymock-2.2.jar
libs/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar
libs/org/hibernate/hibernate-envers/4.1.0.Final/hibernate-envers-4.1.0.Final.jar
libs/com/google/inject/guice/3.0/guice-3.0.jar
...
and then we convert this into usable classpath and run the application as follows:
#!/bin/bash
CLASSPATH_FILE=`ls -r1 ${APP-HOME}/classpaths/myapp*.classpath | head -n1`
CLASSPATH=$(cat $CLASSPATH_FILE | sed 's_^libs_ ${APP-HOME}/libs_' | tr -d '\n' | tr -d '\r' | sed 's_.jar/libs/_.jar:/libs/_g' | sed 's_.pom/libs/_.pom:/libs/_g')
java -d64 -cp $CLASSPATH com.blah.main.Main $#
We have never run into problems and these classpath entries gets pretty huge.
EDIT: As a side note, you can use the maven dependency plugin to generate a list of dependencies.
See this stackoverflow answer about maximum linux command line lengths.
The maximum command line length will be roughly between 128KB and 2MB.
The max size of any one argument is considerably smaller, though, and 9000 chars might be problematic.
When you use in your Java program some classes from a jar file that is specified in the classpath variable, the JVM won't load that class until your running program will explicitly need that class (or if you load that class explicitly from your code - the same idea). The only problem that can appear when you have a very long classpath, is the time needed for classpath checking before the JVM find the right jar file. But that should not be a problem. If your program behaves well in tests, you should not be worried about this.
I'm trying to compile a Java project under Cygwin using a native Win32 Java.
The Java binaries are correctly found under /cygdrive/c/jdk/bin on my machine.
The following command works fine:
javac -d . ./gnu/kawa/util/PreProcess.java
The PreProcess.class file is generated in ./gnu/kawa/util/. Trying to invoke Java on this fails however:
CLASSPATH=.:$CLASSPATH java gnu.kawa.util.PreProcess \
%java6 +use:com.sun.net.httpserver +enable:XML \
`sed -e 's|\([^ ]*\)|./\1|' < ./patch-source-list`
Error: Could not find or load main class gnu.kawa.util.PreProcess
...
This command was invoked by make, that's where the $CLASSPATH variable is set dynamically. patch-source-list is just a list of class names. The : in the classpath looks suspicious, but I'm not sure how to test ; while not annoying sh.
My only other suspicion is that the native Java is trying gnu\kawa\util\PreProcess, but I think cygwin can transparently handle that.
Any ideas? Thanks for your time.
Another option would be to build your path using the ':' and then fix the results using cygpath. This is probably overkill in your specific situation, but in a general case where you may have references to multiple directories, some of which may be referenced as absolute rather than relative paths, or if you are working with cygwin symlinks, it is much more useful.
$ ln -s /cygdrive/c/development/libraries/ ../libs
$ cygpath -pw /cygdrive/c/development/:.:../libs
C:\development\;.;C:\development\libraries\
so then you'd build your CLASSPATH variable as before, and in the final stage run
CLASSPATH="`cygpath -pw "$CLASSPATH"`" java (whatever)
Remember, the JVM has no idea that you are using the cygwin bash shell.
Two things:
for the classpath locations, use the windows path names. Thus, no "/cygdrive/c/somepath", but "c:\somepath\" ("/" and "\" can be used interchangeably however)
use ';' instead of ':' in the classpath list
This should work:
export CLASSPATH="./gnu/kawa/util/PreProcess.class"
CLASSPATH=".;$CLASSPATH" java gnu.kawa.util.PreProcess
The : in the classpath looks suspicious, but I'm not sure how to test ; while not annoying sh.
You're exactly right: you need to use ; instead of :. As for how to use it — as Mat alludes to above, you need to "quote" the semicolon. Any of these will work:
CLASSPATH=.\;$CLASSPATH java Foo
CLASSPATH=.';'$CLASSPATH java Foo
CLASSPATH='.;'$CLASSPATH java Foo
CLASSPATH=".;$CLASSPATH" java Foo
You can use whichever one you like best. (The first uses a backslash, which quotes a single following character. The second and third use single-quotes, which quote a sequence of zero or more characters. The fourth uses double-quotes, which are like single-quotes except that they still allow the variable $CLASSPATH to be expanded. For that matter, you could also write something like
CLASSPATH=".;"$CLASSPATH java Foo
if you want. See the above link for lots more information about quoting in Bash.)