Bugzilla – Full Text Bug Listing
| Summary: | [jar exporter] Provide more functionality with JarExporting | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Rolf <rbiehn> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | benno.baumgartner, daniel_megert, ferenc.hechler, martinae |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Rolf
see bug 219530: add Jar-in-Jar ClassLoader option I'm adding Ferenc, who contributed the Runnable JAR wizard. Ferenc, can you comment? I like the idea.
An option could be added to the Runnable JAR File Export Wizard whether referenced JARs should be packaged into the JAR or copied next to the executable JAR.
In the latter case, all referenced JARs ("ref1.jar", "ref2.jar", ...) could be put into a subdir "lib/" and added to the Manifest Class-Path of the executable JAR ("lib/ref1.jar lib/ref2.jar ...").
The executable JAR can then be started using the -jar option.
Most of the drawbacks mentioned by Rolf might be solved using the JAR in JAR Classloader, but there are other reason, why this solution might be usefull. E.g. when resources have to be accessed as files and not as streams.
feri
We could separate class files from resource files. Classfiles will be packaged into the executable JAR and resource files (like *.properties, configs, ...) will be stored in a resources/ subfolder (parallel to the lib/ folder). Hello Rolf, > I may be able to contribute this code. if you have any questions about how to integrate just ask me (ferenc.hechler@web.de). Best regards, feri Rolf? Do you still need this functionality even if we provide the Jar in Jar classloader? (bug 219530) The idea of the runnable jar wizard is that we generate a jar which can be executed by double-clicking it. If we store the required libraries outside the jar then this won't work anymore. Unfortunately, I won't be able to contribute this code If it's added as part of the manifest class path, then won't the user still be able to double click on it? I still think there is some value in this approach over Jar in Jar i.e.: -easier servicing -as Fernec mentioned accessing resources -It seems "simpler" to me. But the Jar in Jar meets my needs (and I expect most users...) So I can resolve as WORKSFORME if you guys don't see a need for this.... Thanks, -Rolf Hello Rolf, > If it's added as part of the manifest class path, > then won't the user still be able to double click on it? Yes, the jar file will be executable, because the Main-Class is defined in the manifest. Also all external libs have to be set in the Class-Path of the manifest. I think this feature is useful. All the single staps can be done with the normal JAR exporter and manually copying the libs, but to have a wizard to create a distribution with one click looks much better. The user can decide whether he wants an All-in-one-File (Fat-Jar) distribution or a ZIP-File which can be unzipped to be runnable. > So I can resolve as WORKSFORME if you guys don't see a need for this.... I would like to integrate this feature. Because of the dependancy to bug 219530 I would like to do both in one patch. Best regards, feri Will be implemented as part of bug 219530. *** This bug has been marked as a duplicate of bug 219530 *** |