I have a java application from which I build a jar that relies on many third party jars, what's the best/common way of packaging this application for end user distribution?
The best way is to use a build tool like Maven2 or something similar, and use that to manage your dependencies and build a all-in-one package.
Otherwise, you'd mostly be stuck with messing with manifest files. Although, IDEs like Eclipse or NetBeans may help you a bit with that.
The way packaging is done. There are two ways
wrap as executable: This is common, if you know the supportable platform and wrap the Jar in executable. And distribute it. Something like this http://launch4j.sourceforge.net/ (I have not used this, but there are similar wrapper available)
Bundle all Jar and provide script: You can use Maven's Assembly plug-in to bundle everything in one Jar. With this done, you can distribute with a bat file and a .sh file for Windows and Linux based systems respectively. If you see Glassfish is distributed in similar manner. These scripts has executable command and, often take parameters for different behaviors.
You can also use Fat Jar Eclipse Plug-In
OR
Packaging and Deploying Desktop Java Applications in NetBeans
Related
Let's imagine, I created a bunch of command line utilities, written in Scala and/or Java, and I'm using SBT to build them. They all use a couple of libraries, some of them pretty big, and in case of Scala, also the (not so small) Scala standard library.
I want to have these utilities in completely built form (runnable .jar files) to be able to instantly launch any of them and, if needed, also easily distribute them. But what I don't want is to include their dependencies in all of them, because they will be taking disk space. Instead I want them to get dependencies from a shared folder at runtime, and the application jar should contain only "my" classes.
The question is, is there a standard way to accomplish this? If so, where must be shared .jars located? Otherwise, what would you recommend to do?
You can set the CLASSPATH for this.
The JRE searched for classes in the .jar files named in the CLASSPATH.
Additionally all .jar files in the directory jre/lib/ext are used.
To find the complete serching in classpathes please consult the official documentation from Oracle.
Something you might like to consider (although it will require slightly changing what you plan to do) is to have a local Maven repository.
You could have SBT publish libraries to it when they're built. Instead of building runnable JARs, you could run your applications via SBT, which would pull libraries from the local repository as/when required.
The benefit of this is that all the plumbing to do this is built into SBT, and it would make distribution trivial.
The downside is that you would have to run your apps via SBT instead of building runnable JARs. Whether that will work for you, I don't know.
I do not understand the purpose of ant. I read the introduction, but am missing the big picture. I know the following (or at least that I want to use them),
Java
jdbc
hibernate
jsp
servlet container like Tomcat
But I don't see how ant fits in.
Is there some all comprehensive tutorial that tells me how to put all this together?
Why would I want ant? What is the alternative if I don't have ant?
EDIT: So is this sort of the compiling part of its Visual Studio counterpart?
Ant is used as a build system. You do not have to use it--in fact there are quite a few better systems but since ant was one of the first it's still likely to be very common. It generally is used to compile your java files, create wars and often even put the .war files onto the tomcats.
Maven is bigger and tries to do a lot more, but it's also rather strict in it's format and quite heavy--but it's quite common these days as well. Maven can gather all your dependencies automatically which is nice, with ant you still have to download everything yourself.
There are others, but you get the idea.
Response to comment:
I don't use visual studio, but I think it is more limited. For instance, Eclipse can build all your java files into a jar or execute them directly (in fact, it uses ant internally). If you wanted to take your visual stuido "Build configuration" and put it into another tool (Perhaps an automated build system like Jenkins) that doesn't rely on visual studio directly, can you do so?
I guess Ant is the way we code our builds--it's portable betweeen many tools. Visual Studio would be cleaner to "create" your build, but "Exporting" the ability to build would be more difficult (if even possible).
Also ant is portable across operating systems as well as tools. We can switch from Eclipse to Netbeans to IntelliJ without touching our build toolchain.
How would you completely remove visual studio and replace it with slickedit, emacs or vi (if that was your thing, which I'm sure it's not) without starting over from scratch with your build?
For any web application to work you need to package or build all your java code with all the libraries into an web application archive to accomplish this task we need to some tool or library to package into the correct format and some of the libraries which can achieve this is
Apache Ant and Apache Maven
There some good discussions about Ant vs Maven in SO.
You need ant to build the project. Well you can build project using IDE like eclipse etc. But for production purpose and big projects, it always advisable to some build script like ant. Its a script where you can customize what you want to build and what not. you can define what is the output should be like war/jar/ear etc
Other alternative is Maven which is very prevalent and standard now a days
I found some great tutorials for IzPack and it works great at installing my program into a folder. Is it possible to have the contents of those folder wrapped into an executable jar using IzPack? My goal would be to have that executable jar call my python script which launches the application. Let me know what I can do, thanks.
I don't think so. Not because IzPak did not have the capability to do that (it obviously creates the installer's jar), but because it was not designed to do so, AFAIK.
If you want to pack various jars in a single jar file, then you should attack this problem in the build phase of your project. If you use Netbeans, then this link will be useful:
http://java.sun.com/developer/technicalArticles/java_warehouse/single_jar/
About executing the python script... are you using Jython? If not, take into account it is quite difficult to distribute a python program, many apps written in python distribute the interpreter and its required dll's with them.
What's the best option for packaging and distributing a command line application written in Java, targetting OS/X and Unix?
The executable jar option seems fairly robust, and my distribution doesn't need to be super fancy, so right now I'm just thinking of plonking a bash script next to that with the relevant java invocation and being done with it.
I'm wondering if there's something similar to python's bdist package that would let me easily make nice installers for both target platforms. Or if there's some more obvious way that I'm missing where I can turn the entire distribution in to a executable file that wraps the jar in some way.
Since you are providing a CLI application it may be easiest to just provide the script you already mentioned. I usually try to keep it self-contained, e. g. not referencing external paths / using only relative paths etc. And maybe a readme.txt file.
If you would like to provide a full-blown installer, you might want to take a look at IzPack, a tool for generating installers for Java deliverables. It also allows the wizard to run in console mode, if you do not have a graphical environment available for installation (see the "Features" page in the link above).
my application needs multiple jars to work. Since it is a desktop application i can not hold the user responsible of installing. So in my build script i unzip the jars content in to my build directory delete manifest files, compile my software and jar it again. Everything works as it should my question is are there any long term side effects to this process?
In the past, there were JARs with weird content (like the DB2 driver which contains com.ibm and com.IBM; after decompressing in a Windows filesystem, those two packages would be merged).
The only issue you need to be aware of are signed jars and other files in META-INF which might have the same name in multiple source JARs.
A simple solution for all these issues is to use One-JAR. It allows to wrap several JARs into one without unpacking them, first. And read this answer: Easiest way to merge a release into one JAR file
A simpler solution (IMO) is using Maven's assembly plugin, which is also described in one of the answers to another question which was linked to in a previous Q&A. This is provided you are using Maven (which is a recommended tool by its own right) as a build tool.
If you want a no fuss way for the end user to kick off a program with multiple jar dependencies you may want to look at Launch4j or Jsmooth (I prefer Launch4j). Both are programs that create executables that wrap jar(s) and the JRE together so that to the end user it appears no different then any other executable.
Another great option is ProGuard, which can also shrink and/or obfuscate the code too.
If your primary target platform is Windows desktop, then you could also consider generating an Windows native exe from the jars of your application
If some of the jars are signed you lose the signature by unpacking/repacking it.
Well you're throwing away the MANIFEST of your third party jars, so that could cause you problems. For example you could be causing security issues by throwing away the "Sealed" attribute.
Why not just create a simple installer and a script to launch your application which sets the CLASSPATH correctly?
One-JAR will do the job, and has a new release (0.97) which supports frameworks like Spring and Guice, which users are now packing into One-JAR archives. http://one-jar.sourceforge.net
Ference Hechler also did some great work inside Eclipse with the Eclipse export wizard: we worked together on FatJar/One-JAR from which the Eclipse work grew, and I can recommend that as an approach, though I don't know how well it handles the frameworks.