Whats best way to package a Java Application with lots of dependencies?

Question

I\'m writing a java app using eclipse which references a few external jars and requires some config files to be user accessable.

1. What is the best way to pac

Answer 1

Ant. It's not the best thing in the world, but it's standard, it's apache, and it works. There's some good examples on the web how to make a simple build.xml for any, and it's got some features like the 'war' task that knows how to put all the basic stuff (classes, web.xml etc) in the jar file for you. You can also tell it to pick up other config files and jars and it will happily do it. It's also really smart about what to compile. You give it a directory, and it finds all the java files and builds them only if their classfile is out of date, so you get some of the traditional make functionality for free without much effort.

Answer 2

Well, if you are speaking of deployment of a standalone desktop application:

Before we switched to web start we have been creating three deployment archives, one for windows, one for mac and one for other platforms.

On windows we have successfully used the Nullsoft Scriptable Install System (known for it's usage by the older winamp versions) and its ant task, although some drawbacks are:

• It is only usable on windows AFAIR
• You have to do some work by hand, i.e. customizing the wizard-created script AFAIR

It can create a windows installation with start menu entries on the other hand. There also exists an eclipse plugin for integrated NSIS shell script editing.

On Mac OS X there is an ant task to create an .app file from your java files so that you can start it like a native os x application. But beware of not writing any setting to your home dir and using the the application dir instead.

For others you have to expect they are in a un*x env and deploy your app with a shell script to start the application.

In any case you may have to deploy your custom policy file to get access rights for your application.

If you want to get rid of all the packaging and stuff you should seriously consider using web start. We have saved much time since switching to it, i.e. simplified our deployment process, takes care of updates etc.

Update 2014

Use maven assembly plugin, see section "Creating an executable jar"

Answer 3

You should try FatJar. It's an Eclipse plugin that with just a right click at the Project can build a JAR file with all you need to run the application, including the necesary third party JAR.

We use it everyday, in conjuction with JSmooth to create the executables, to deploy our software packages to our customers, and works like a charm.

Answer 4

There is no one 'best way'. It depends on whether you are deploying a swing application, webstart, applet, library or web application. Each is different.

On point 2, you are correct. Jar files cannot contain other jar files. (Well, technically they can, its just that the inner jar file won't be on your classpath, effectively meaning that jar files do not contain jar files).

On point 3, you certainly can reference config files outside the jar file. You can typically reference a config file as a file or a resource. If you use the resource approach, it typically comes from the classpath (can be in a jar). If you use a file, then you specify the filename (not in a jar).

In general, most Java developers would use Apache Ant to achieve deployment. Its well documented, so take a look.

Answer 5

(1) An alternative to ant that you may wish to consider is maven.

A brief intro to maven can be found here.

For building a JAR, maven has the jar plugin, which can automate the process of ensuring all dependent jars are listed in your jar's manifest.

If you're using eclipse, then download the maven integration as well.

(2) Another alternative is to use OneJar (disclaimer: haven't tried this myself).

Answer 6

You could look at other java projects (e.g. JMeter, SquirrelSQL, JEdit, Cernunnos, etc.). Each package their applications slightly differently, so consider your goals when you review these.