This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have Dawn & David Griffiths on-line!
See this thread for details.
The moose likes Java in General and the fly likes Issues deploying Java application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Issues deploying Java application" Watch "Issues deploying Java application" New topic

Issues deploying Java application

Adam Schweitzer

Joined: May 26, 2006
Posts: 17
I have a Java application that I run using the Eclipse IDE. I need to export this such that my coworkers will be able to use it, preferably without having to install Eclipse as well. The problem is, when I export a jar file of the program, it does not work. I have identified two possible reasons why this may be so (I have been able to successfully distribute other applications that did not have these complicating factors):

1) The application links to another project in Eclipse. By default (am I missing a setting?), Eclipse does not include this when I export as a .jar file. The solution (workaround?) is to manually select this other project. This does not completely solve the problem, however, as the linked project uses a library .jar (the Saxon XSLT processor, FWIW) file which is not included in the application .jar no matter what I have tried.

2) The application reads from files contained in the project. This is fine in Eclipse, but not when I export - as these files (XSLT stylesheets, FWIW) are located inside the .jar file, and cannot be read (ie. (new File("Stylesheet.xsl")).exists() returns false).

How would I go about resolving these issues?

Rob Spoor

Joined: Oct 27, 2005
Posts: 20049

1) Put all the JAR files needed by the library in a folder called "lib" or something, then change the manifest file to include the Class-Path. For example:
That does mean that any referenced projects must be put into a JAR file as well.

2) Use Class.getResource, Class.getResourceAsStream, ClassLoader.getResource and ClassLoader.getResourceAsStream instead of File. Put the resources in your JAR file as well. That does mean you can't write to those files, but if you need to you can use a file / folder based on System.getProperty("user.home").

How To Ask Questions How To Answer Questions
Adam Schweitzer

Joined: May 26, 2006
Posts: 17
If I'm understanding you correctly, this means I end up with three files:

Is there not a way to package this up so I only have one file in the end?
David Newton

Joined: Sep 29, 2008
Posts: 12617

There are a few projects on the web that will let you create a single jar out of multiple jars, jarjar for example.
Paul Clapham

Joined: Oct 14, 2005
Posts: 19693

Adam Schweitzer wrote:Is there not a way to package this up so I only have one file in the end?

I've seen this question repeatedly and I don't understand it. What's wrong with distributing three jar files?
Rob Spoor

Joined: Oct 27, 2005
Posts: 20049

Beats me. Windows applications often come with several additional DLL files and the like, and nobody cares about those.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14916

David Newton wrote:There are a few projects on the web that will let you create a single jar out of multiple jars, jarjar for example.

Another such utility is One-JAR.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Adam Schweitzer

Joined: May 26, 2006
Posts: 17
Well, the reason I'd like to have a single file is it makes things a bit easier and less prone to errors on the part of users (ex. if they don't copy all the necessary files). And I know in a Java EE context, there are .war and .ear files to bundle apps together. Anyway, not a big deal..

I have run into a problem, though, with replacing File's with InputStreams:



In either case, I can successfully read the file. However, when I try to use the InputStream as an xslt stylesheet and perform a transformation using the Saxon XSLT processor, I get the following error:

Error at xsl:include on line 77 of file:/C:/Documents and Settings/aschweitzer/workspace/XMLPublisher/:
Failure reading file:/C:/Documents and Settings/aschweitzer/workspace/Common/variables.xsl: no more input

The relevant line in main.xsl is:
<xsl:include href="../Common/variables.xsl"/>

I don't understand why it is looking for this file in the wrong location:
file:/C:/Documents and Settings/aschweitzer/workspace/Common/variables.xsl

instead of:
file:/C:/Documents and Settings/aschweitzer/workspace/XMLPublisher/Stylesheets/Common/variables.xsl

Can someone explain this? This is only a problem when the stylesheet includes another one(otherwise, it works fine).
Adam Schweitzer

Joined: May 26, 2006
Posts: 17
Can anyone help me with this? (Maybe I should ask on an XSLT forum?)

Perhaps I didn't explain it well in my last post. Here is a bit more detail:

I am having a problem with trying to export an application which performs XSLT transformations as a .jar file. The issues are twofold:
1) The transformer looks in the wrong location for the included stylesheet.
2) The transformer does not look for the included stylesheet in a jar file.

Here is the relevant code:

code snippet:

stylesheet, s1 (location: stylesheets/s1.xsl):

stylesheet, s2 (location: stylesheets/s2.xsl):

The code as written executes successfully, with expected results. The problem is when I try to change line (1) to be compatible with the stylesheet being in a .jar file:

When I execute the program, an exception is thrown saying that it could not compile the stylesheet, because it could not find s2.xsl. It is looking for it at the program root rather than in the stylesheets folder. If I move s2.xsl outside of the stylesheets folder, the program executes correctly. I do not understand why it is looking for s2 in the wrong place?

When I export the application as a .jar file (with copies of s2.xsl in both places (why?) where it may be looked for), the program throws an exception when I try to run it. Instead of looking for s2.xsl inside the jar file, it looks for it on the file system.

Any ideas what I can do to fix this?

Don't get me started about those stupid light bulbs.
subject: Issues deploying Java application
It's not a secret anymore!