Re: plugin jar: A better way to add custom classpath entries in manifest file?
--- Tim Kettler <[EMAIL PROTECTED]> schrieb am Do, 5.6.2008: > it seems this is > a misunderstanding on your side. The constructor you are > using is intended to load images out of files on the > filesystem and not to load an image from a classpath > resource. The correct way to load images from > resources would be to get a stream of the resource from a > classloader and then pass this to the image constructor. I tried all this and it didn't work. It worked, of course, after I changed the manifest. But the simple solution works then either. The problem with streams is that You have to close them (without closing the image). So it works that way, why not use it? Why producing overhead instantiations? If You have 200 images in Your app You wouldn't open and close 200 streams! > I don't understand why this helps in your situation Because when the app has NO outside resource it looks for additional paths in the jar file too WITHOUT extra classpath entries. But, as I said, I have outside resources like config files. A classpath entry in manifest forces the app to look inside the jar. > but the need to add the 'img' directory to the > classpath should go away > if you load the images properly as classpath resources. No, this had no effect, I have tested all variants. __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin jar: A better way to add custom classpath entries in manifest file?
Hi, Maximilian Eberl schrieb: The problem: I have resources OUTSIDE the jar like config files that have to be edited by the user and resources IN the jar, so that the user cannot accidently delete or willingly replace them. Images, for example. Using those in a (SWT-)class would look like: Image img01 = new Image(display, "/img/nice.png"); This will look up for a file nice.png in a subfolder "img" packed in the jar along with the classes: JAR --com/mycompany/swtapp/MyClass.class |-img/nice.png I'm no SWT expert, but looking at the Image Javadoc [1] it seems this is a misunderstanding on your side. The constructor you are using is intended to load images out of files on the filesystem and not to load an image from a classpath resource. The correct way to load images from resources would be to get a stream of the resource from a classloader and then pass this to the image constructor. Or I'm just reading the javadoc completely wrong or just misunderstood you ;-) But ONLY if the manifest File contains an extra entry I don't understand why this helps in your situation in the first place but the need to add the 'img' directory to the classpath should go away if you load the images properly as classpath resources. ClassPath: img If this is not explicitely written in the MANIFEST.MF, the app throws a NullPointer. I tried the tag: true but this only adds the dependency classpath Do I have to define the img-folder as a dependency? I tried to use img but mvn didn't recognize the tag (of course). I had to specify a custom manifest file with src/main/META-INF/MANIFEST.MF looking like this: Main-Class: com/mycompany/swtapp/App Class-Path: img just for the simple Task of adding a ClassPath entry to the manifest file. OK, it did what I expected, but isn't there a more elegant way to do it? For example a simple -Tag in the archiver plugin could do the work. -Tim [1] http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/Image.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
