8

I have a Java console application that I am ready to deploy onto a Unix server. I am writing a shell script to run the application.

I plan to put my shell scripts in one folder, my application jar and dependent jars (spring, etc.) into a different folder and properties files (those that need to be maintained 'live') in a separate folder again. I would then have my shell script iterate through the files in the 'jars' and 'properties' folders, appending them to the classpath, before finally calling java ...

Is this a 'good' deployment structure? Are there any guidelines for how to arrange files to maximise maintainability and stability? Are there obvious 'wrong' ways to do this that are best avoided?

I should add that, for a previous project, I put all shell scripts (those that start java processes and those that don't) into a scripts folder, my application jar into a folder with the library jars in a library subfolder and external resources into a config subfolder. I then wrote a script that explicitly loads all the files. It was long winded to write and needs to be maintained whenever I upgrade a library jar. This time around I'd like to do it better. Also, it feels unnecessary to separate my application JAR from the libraries.

Improve this question
2
  • 1
    Maven could create a Manifest file for your jar with references to your library jars, then java itself would find those files. Also depending on how you "look" for the properties files you could get away with a single classpath entry for those. The job of writing the shell script would then be much reduced. Commented Dec 3, 2012 at 18:51
  • Thanks. I'll investigate using the maven-jar-pluging to ease my workload. I'd forgotten that manifest files could do this. Commented Dec 7, 2012 at 15:37

4 Answers 4

Reset to default
2

For what it's worth, this is what we use;

/ /class //package hierarchy here, raw .class files /lib //library jars here, apache commons, gson etc, all .jars /conf //.properties files go here, including ones for libraries /doc //program documentation files, typically .txt /javadocs //java doc html root /sh //shell scripts including execute.sh and compile.sh

We use ant for building, often have a src folder for the source tree if necessary. This way you just add /class and /lib to your classpath, and that never changes.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

This is what I had in mind. I guess it's good to see that it is used elsewhere.
1

Good structure for your case is so called uberJar or oneJar, that can be made with number of utils, just google it. Also I can recommend such a nice piece of code as http://www.jdotsoft.com/JarClassLoader.php

Improve this answer

2 Comments

I can see how that would make classpaths and deployment easier. My concern is that it hides the actual libraries used in the deployment. Whilst it's theoretically possible to determine which versions of which jars were packaged in the uberjar, I can see the average maintainer having cause for concern.
check JarClassloader, it allows nested jars.
1

Frankly, if it is just a small app, I would put it all under /opt/<my_java_app> and have a directory substructure there just like you did in dev.

If you want to be more compliant with the UNIX recommended practices, then put your executable (including your jar) in /usr/local/bin/<my_java_app>, config files in /etc/<my_java_app>, log files and other data files in /var/<my_java_app>.

Also, you may want to refer to this document.

Improve this answer

Comments

0

Build a system-native package, and use system defaults. If using Debian, create a .deb direct from your build system (for instance, using ant deb task). If using rpms, use the rpm task. That way you can easily deploy, undeploy and update the application just like any other one.

The system package should separate libraries (I use /usr/share/java/AppName for my jars) and configuration (to /etc/AppName or /home/UserName/.AppName); the launch-scripts I symlink to /usr/bin. Beyond that, there is no great complication getting things to work. I recommend finding well-known java-based packages in your distribution and copying their launch scripts (in particular, their VM-locating magic).

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.