 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / March 2005javahelp problem
Hi all! I have equpied my application with help in the form of javahelp. Now i have a problem with the program. I previously had all my files in a jar. Once I've included javahelp I can no longer have an exectuable jar. From the error-messages I got a security exception, that was resolved by excluding the jh.jar from my jar and have that seprataly. No problem. BUT I can not run an exectuable jar now. It refuses to find the classes needed for the javahelp system. How do I resolve this? I've tried with classpaths and other things, but not succeeded. I want to distribute it as a single jar, or possibly as two jars, and nothing more. Is that possible? /daniel > I have equpied my application with help in the form of javahelp. Now i > have a problem with the program. I previously had all my files in a [quoted text clipped - 6 lines] > I want to distribute it as a single jar, or possibly as two jars, and > nothing more. Is that possible? I would start by posting enough detail so that there is some hope that someone would be able to tell what the problem is. What error messages are you getting? What is your classpath set to? It sounds like you had it working at one time. Is that true? If so, what have you changed since then?  SignatureRegards, John McGrath >> I have equpied my application with help in the form of javahelp. Now i >> have a problem with the program. I previously had all my files in a [quoted text clipped - 12 lines] >it working at one time. Is that true? If so, what have you changed since >then? true, sorry. I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have not changed my classpath. If I run it inside my IDE (JBuilder) it works fine. But out side of it, it just doesn't work. I've tried in the manifiest to set the classpath to .;./jh.jar but it didn't help. I did in the mainmethod try to set the classpath via the System.setProperty method, to /current/run/path/jh.jar. But that didn't help. I'm just curious how others have managed to distribute their javahelp enabled programs into single jars, if that is how it's done. What am I missing? /daniel >>>I have equpied my application with help in the form of javahelp. Now i >>>have a problem with the program. I previously had all my files in a [quoted text clipped - 26 lines] > > /daniel I don't know if the JavaHelp license allows it, but you could unjar the jh.jar and add these to your application's jar. A second possibility is to set the 'Class-Path:' attribute in the Manifest of your application's jar. See <http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main%20Attributes>. SignatureRegards, Roland de Ruiter ___ ___ /__/ w_/ /__/ / \ /_/ / \ >>>> I have equpied my application with help in the form of javahelp. Now i >>>> have a problem with the program. I previously had all my files in a [quoted text clipped - 33 lines] > Manifest of your application's jar. See > <http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main%20Attributes>. I'm having a similar problem. I've been using ProGuard to unpackage my various jar's that I use, identify only the classes that are actually used, and bundle the whole lot up into a single JAR file. But when I try this with the javahelp jar, I get the same security exception. It seems that this is because the javahelp jar is a signed jar, and the classes in the jar are checking to see that the jar is still signed. Obviously, when I repackage it, I break the signatures, because I'm not including the original jh.jar MANIFEST.INF in my new jar, and this is what contains the signatures (well, the hashes, anyway!) I worked around this by not packaging up the javahelp jar, and simply requiring people to have it installed. Not ideal, however. Rogan SignatureRogan Dawes *ALL* messages to discard@dawes.za.net will be dropped, and added to my blacklist. Please respond to "nntp AT dawes DOT za DOT net" > I worked around this by not packaging up the javahelp jar, and simply > requiring people to have it installed. > > Not ideal, however. Why is this not ideal? All you need to do is list the JAR file in the manifest "Class-Path" attribute and place the JAR file in the same directory as the main JAR. SignatureRegards, John McGrath >>I worked around this by not packaging up the javahelp jar, and simply >>requiring people to have it installed. [quoted text clipped - 4 lines] > manifest "Class-Path" attribute and place the JAR file in the same > directory as the main JAR. The whole point of using ProGuard was to make a single executable distribution, which does not require installation, or any other actions by the user. Prior to trying to include the JavaHelp support, this worked fine. But adding javahelp broke this distribution model, forcing users to manually download the javahelp jar, place it in the extensions directory (or the local dir), etc. It's just more work than I wanted to make them do . . . Yes, I do have an "installer" option, but the file is almost 3 times the size, because it distributes un-"cut-down" libraries . . . Rogan SignatureRogan Dawes *ALL* messages to discard@dawes.za.net will be dropped, and added to my blacklist. Please respond to "nntp AT dawes DOT za DOT net" >>> I worked around this by not packaging up the javahelp jar, and simply >>> requiring people to have it installed. [quoted text clipped - 20 lines] > > Rogan You could tell ProGuard to leave all javax.help classes untouched. One or two years ago I created an application in a single jar that was obfuscated by ProGuard and it included the JavaHelp files (unobfuscated). I just had a look at this jar and the manifest directory doesn't contain the SHA digests nor the Sun_micr.rsa and Sun_micr.rf files of jh.jar. Like I said before, I don't know if the JavaHelp license allows you to do it, but you could try to package a single application without the JavaHelp signature entries. SignatureRegards, Roland de Ruiter ___ ___ /__/ w_/ /__/ / \ /_/ / \ >>> I worked around this by not packaging up the javahelp jar, and simply >>> requiring people to have it installed. >>> >>> Not ideal, however. > ... > It's just more work than I wanted to make them do . . . What I've done in the past is to add the library into the classpath, then include the library jar within my jar (obviously it won't run like this), then spit the library out on startup. I just compare checksums between internal and external versions of the file, and overwrite the library if they're different (or if the lib is missing). This has the advantage of a single jar distribution, but the disadvantage of having to re-release your stuff just to upgrade a library. -- Shane > true, sorry. > I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have > not changed my classpath. The JVM classpath settings via the command line or the environment variable are ignored when you run an application from a jar with the -jar option. This is clearly documented in the particular "java" manual page which comes which every JDK (hint, hint :-)). You need to provide a Class-Path attribute in your jar. This is also documented in the JDK documentation ... /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq > I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have > not changed my classpath. If I run it inside my IDE (JBuilder) it > works fine. But out side of it, it just doesn't work. Outside of it? Or when you package your application in a JAR file? > I've tried in the manifiest to set the classpath to .;./jh.jar but > it didn't help. And might we see the manifest file? > I did in the mainmethod try to set the classpath via the > System.setProperty method, to /current/run/path/jh.jar. But > that didn't help. That won't work. The application ClassLoader is initialized using the value of the system property "java.class.path" early on in the JVM initialization, and obviously before your main() method runs, since the ClassLoader had to load it. Setting the property after that will have no effect on the ClassLoader. > I'm just curious how others have managed to distribute their javahelp > enabled programs into single jars, if that is how it's done. What am I > missing? I have never done that. I think it works much better if you use separate jar files for the major components of an application. I can not think of any advantages in bundling them into a single JAR file, and I can think of multiple disadvantages. If you put everything into a single JAR, you run the risk of messing up something in third-party libraries. It also makes it much more difficult to upgrade to a newer version of libraries without rebuilding your entire application. Even with your own JAR files, there are advantages in using separate JAR files. For example, I have always distributed the JavaHelp content for an application as a separate JAR file. Such content is generally produced by different people than the main application code. Keeping them separate allows them to create the help content using their own procedures, then place the file in the right place and run the application. If the content were mixed in with the main code, this would be much more difficult. SignatureRegards, John McGrath >> I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have >> not changed my classpath. If I run it inside my IDE (JBuilder) it >> works fine. But out side of it, it just doesn't work. > >Outside of it? Or when you package your application in a JAR file? When I try to run my application as a standalone program, i.e not in the IDE. But if I do not directly specify to run it as a jar but with "java -cp .;./jh.jar MyMainClass" it works. > I've tried in the manifiest to set the classpath to .;./jh.jar but >> it didn't help. > >And might we see the manifest file? sure. Manifest-Version: 1.0 Main-Class: MyMainClass Class-Path: .;./jh.jar that's it. With the knowledge I have now I think this should work. But apprantly I miss something. >That won't work. The application ClassLoader is initialized using the so I discovered. I guess some more reading on my part would not have hurt. But I still think that my manifiest should work. And that was my first idea, and first thing I tried. >I have never done that. I think it works much better if you use separate >jar files for the major components of an application. I can not think of >any advantages in bundling them into a single JAR file, and I can think of >multiple disadvantages. Yes, I defintly see your point here. But in this special case it is a small application used to program dishwashers, and the users is not very good with computers. So it must be easy to distribute, no installation would be absolutley preferable. >different people than the main application code. Keeping them separate >allows them to create the help content using their own procedures, then that was my idea as well. to keep localization and help and such in a separate file. But my employer did not really share my idea here. They want one file. They even considered taking the help out of the program because of this businiess with the jh.jar. Luckily it seems they keep it now, but more than two files... I wouldn't bet any money on it :) thanks for your input! /daniel Oh! Now I saw where I went wrong. I used ";" instead of " " in the classpath definition. Probably I'm used to setting the classpath at the commandline, where ; is needed. Oh well. Thank you everyone for your valueable support! regards Daniel >>> I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have >>> not changed my classpath. If I run it inside my IDE (JBuilder) it [quoted text clipped - 45 lines] > >/daniel >>>I get a "java.lang.NoClassDefFoundError: javax/help/HelpSet". I have >>>not changed my classpath. If I run it inside my IDE (JBuilder) it [quoted text clipped - 20 lines] > >... In the jar-file you have to separate the items in your class path with spaces, not ";". So it should be: Class-Path: . ./jh.jar Paul. > Class-Path: .;./jh.jar Aside from the semicolon issue, are you sure you want to put "." on the classpath? That would only have an effect if you are putting class files (or other resources) in the same directory that contains the JAR file, or in subdirectories. Given that you want everything in a single file, I wonder if that is needed. SignatureRegards, John McGrath >> Class-Path: .;./jh.jar > [quoted text clipped - 3 lines] >in subdirectories. Given that you want everything in a single file, I >wonder if that is needed. My experience tells me it is needed, but, I will try to remove it. As I have all my resources in now two jar files. I thought the "." was needed to make the jvm look for my classes etc in the jar. I will read a bit more about jars and then come to a decision. > I thought the "." was needed to make the jvm look for my classes > etc in the jar. No, when you use "java -jar", the named jar file is automatically put on the classpath. SignatureRegards, John McGrath Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.