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).
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").
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:
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
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).
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:
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?
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop