Community
Participate
Working Groups
Hello, the following enhancement could be included into the JDT (JAR-Export-Wizard): Create an executable JAR file (with "java -jar xxx.jar") from a java project including all referenced libraries and sub-projects. This can be achieved by unzipping all referenced JARs and zipping all classes together with the project output into a new jar. Another solution could be to write a specialised Class-Loader which handles JAR-Files inside a JAR. I have written a Plug-In called Fat-Jar which implements this feature http://fjep.sourceforge.net Now I would like to help integrate it into the Eclipse platform and asked how to get involved. The answer was to start an enhancement request in bugzilla. So this first step is done.... ;) Best regards, Ferenc Hechler
*** Bug 83259 has been marked as a duplicate of this bug. ***
Move to JDT/UI
The new release 0.0.17 of Fat-Jar supports the generation of an ANT script which can be used to build the executable jar inside and outside of Eclipse. This feature was asked often for autmation of the build-process.
Ferenc, our current focus is to get J2SE 5.0 into 3.1. As long as this isn't complete we decided to not add any additional features. So this is time permitted only.
reopen for 3.3 planing
Ferenc, are you still interested in adding your plugin to jdt? Important for us is that we can rely on your help regarding maintenance.
Hello Martin, yes I am still interested in adding Fat-Jar to JDT. About Maintanance: the project started in 2004 and we had 23 alpha releases, mostly bugfixes and enhancements reported by users. Sorry for responding so late, but I am currently on holliday till 25. July. Best regards, feri
*** Bug 151057 has been marked as a duplicate of this bug. ***
I have been looking at the one-jar class loader which is utilized by fjep, as we were looking into making the executable jar compatible with Web Start, and it makes a lot of assumptions which needs to be looked into. I have done some of the work (not contributed back yet), but it would be very beneficial to have a classloader guru (there must be some on the eclipse staff) look it over. I would like to contribute work on integrating this functionality in stock eclipse.
Any news here, Thorbjørn? Such a contribution would be highly welcome!
Feri and Thorbjørn, of course.
Attempts have been made at collaborating off list, but has not yet succeeded. What is the 3.3 timeframe?
If you change has impact on the jdt.ui public API: End of January 2007. If not: March 2007. But remember that we need some time to review and get PMC/legal approval. The earlier I can give comment to the chosen solution, the better. My understanding is that this would be an extension of the existing JAR wizard, that also preserves all existing functionality.
I have established contact with Thorbjørn again, so we hopefully get on further. I am still unsure about Simon Tuffs oppinion about the One-Jar license. One-Jar is integrated into Fat-Jar and uses a BSD-style license. I will ask him.
Simons answer about using one-jar: ---------------------------------- Short answer: I see no problems incorporating OneJar into the Eclipse JDT.
An integration project is set up on sourceforge. CVS: ":pserver:anonymous@fjep.cvs.sourceforge.net:/cvsroot/fjep" Module: "FatJarJdtIntegration" It is a Plug-In Project which contains a copy of the "Java/JAR File" exporter renamed to "Java/FATJAR File" exporter. The progress can be found here: http://fjep.cvs.sourceforge.net/*checkout*/fjep/FatJarJdtIntegration/info/status.txt Any comments and suggestions are welcome. ;)
A first release can be downloaded here http://downloads.sourceforge.net/fjep/FatJarJdtIntegration_0.0.1.zip?download Quickstart: * "Export..." > "FAT-JAR file" * select a launch config * click "set ClassPath" * click "Check all" * click "Finish" The idea is to use the classpath of a launchconfig to identify the resources to export. The "resources to export"-tree was changed to show jars and classes-folders. Also the MainClass is read from the launch-config. The manual steps should be automated in a later version. Details can be found here: http://fjep.cvs.sourceforge.net/*checkout*/fjep/FatJarJdtIntegration/info/status.txt Best regards, feri
The second release can be downloaded here http://downloads.sourceforge.net/fjep/FatJarJdtIntegration_0.0.2.zip?download Quickstart: * "Export..." > "FAT-JAR file" * click "enable fat-jar" * select a launch config * click "set ClassPath" * click "Finish" new: enable/disable fat-jar, merge manifests, remove signers, manifest Class-Path Details can be found here: http://fjep.cvs.sourceforge.net/*checkout*/fjep/FatJarJdtIntegration/info/status.txt Best regards, feri
The third release is worth a closer look. The Fat-Jar functionality is nearly complete. download: http://downloads.sourceforge.net/fjep/FatJarJdtIntegration_0.0.3.zip?download description: http://fjep.cvs.sourceforge.net/*checkout*/fjep/FatJarJdtIntegration/info/status.txt Any feedback welcome.
The One-Jar ClassLoader is added. download: http://downloads.sourceforge.net/fjep/FatJarJdtIntegration_0.0.5.zip?download description: http://fjep.cvs.sourceforge.net/*checkout*/fjep/FatJarJdtIntegration/info/status.txt
Created attachment 79147 [details] proposed fix Hi Feri First, thanks for this cool feature. I did a review of your code and made some changes. I've also wrote unit tests. The biggest change is that I've removed the generic UI. I leave the existing wizard as is and add a new Runnable JAR export wizard. The R-JAR wizard is as simple as possible: The user only has to select a destination and a launch configuration. Both wizards share a common superclass: the AbstractJarDestinationWizardPage. The JarFileExportOperation still uses the JarBuilder you've introduced, I like that very much. I've just simplified the code there and removed dependencies on internal classes. I've also turned the JarBuilder form an interface into an abstract class. So, now, the extension point is gone. I'm not convinced that it is necessary. To implement a new jar building strategy one can now: 1. Add a new wizard and subclass AbstractJarDestinationWizardPage 2. Implement a new JarBuilder IMHO that's good enough. But it's not that I feel very strong about this. Jardesc are not supported by the fat jar wizard. I think it makes not that much sense to have jardecs for this wizard because the wizard is very simple. But the code is still there, we can enable it if someone asks for it. The UI does not have the 3 options: merge manifests, remove signers, and manifest classpath separator. Does it ever make sense to change this options? Can't we find defaults which are always good? If a project does not have a launch config attached you do generate a default launch config. But this config does not have a main type and the resulting jar is therefore not runnable. I see 3 solutions: 1. Don't support this for project without launch configs 2. Only support it for projects containing exactly one main type (and search for it) 3. Allow to browse for the main type in the wizard I opt for 1. Mmm, I think that's about it. Personally I think this is a great feature and It should really make it into 3.4. It would therefore be great if you could review my changes and give feedback. Of course we will also need your (and from other authors if any) approval to add this code to the eclipse code base.
Created attachment 79149 [details] icons
Created attachment 79409 [details] proposed fix Working on the FatJarPackagWizardPage, removed the default launch config stuff.
Created attachment 79480 [details] proposed fix
Created attachment 79721 [details] fix Work on API Added IP issue warning dialog Only allow to select java application launch configurations
Created attachment 79792 [details] fix only added contribution comments
Created attachment 79929 [details] patch for org.eclipse.jdt.ui.tests only this patch replaces only the test-part (org.eclipse.jdt.ui.tests) of the previous fix. NEW: * the created "runnable"-jars are executed and the console-output is checked. * An test for signed jars has been added Two libs (binary) have to be added to the folder testresources/ to run all tests (see next attachment). * mylib_stdout.jar, similair to mylib.jar. On creation of Foo "created mylib.Foo" is output to stdout * mylib_sig.jar, signed version of mylib_stdout.jar
Created attachment 79930 [details] testresources for previous patch addition to patch 79929, see description there.
(In reply to comment #27) > Created an attachment (id=79929) [details] > patch for org.eclipse.jdt.ui.tests only > > this patch replaces only the test-part (org.eclipse.jdt.ui.tests) of the > previous fix. > > NEW: > * the created "runnable"-jars are executed and the console-output is checked. > * An test for signed jars has been added > > Two libs (binary) have to be added to the folder testresources/ to run all > tests (see next attachment). > * mylib_stdout.jar, similair to mylib.jar. On creation of Foo "created > mylib.Foo" is output to stdout > * mylib_sig.jar, signed version of mylib_stdout.jar > Wow, thanks for the tests. But we did not execute the runnable jar because of the risk such a test has. We have to run this tests on several platforms, they have to work on each. Also due to the timeout stuff it is possible that we'll get random test failures, it is important for us that we have reliable tests. That been said, I'm willing to release such tests and give it a try, with the option to remove it if we can not get reliable results. But the tests fail if I run with a 1.5 vm: ERROR: exitcode=1, stdout=[], stderr=[Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.eclipse.jdt.ui.test.Main.main(Main.java:5) ] if I run with a 1.4 vm I get the same plus a error dialog. This on WinXP.
Created attachment 80060 [details] testresources for previous patch compiled with java 1.3, so the 1.5 problems are solved.
The problems using JRE 1.4 are a result from useing the helper Class org.eclipse.jdt.ui.tests.core.ProjectTestSetup. The Description: ProjectTestSetup sets up an 1.5 project with rtstubs15.jar and compiler, code formatting, code generation, and template options.
Created attachment 80120 [details] testresources for previous patch no compatible with java 1.4 - replaced Class.getCanonicalName() with Class.getName()
could not create a new patch for the tests, because cvs was not reachable. After changing the setup method of FatJarExportTest as follows: [---] protected void setUp() throws Exception { fProject= ProjectTestSetup.getProject(); Map options= fProject.getOptions(false); String compliance = JavaCore.VERSION_1_4; JavaModelUtil.setCompilanceOptions(options, compliance); JavaModelUtil.setDefaultClassfileOptions(options, compliance); fProject.setOptions(options); [---] the tests are running under 1.4, 1.5 and 1.6 Also the Foo method had to be changed, because it used Class.getCanonicalName() which is since 1.5: [---] private static String getFooContent() { ... buf.append(" System.out.println(\"created \" + Foo.class.getName());\n"); [---] I uploaded new libs which are compatible with 1.4. I will add the patch soon
Created attachment 80161 [details] patch for org.eclipse.jdt.ui.tests only replacement for attachment 79929 [details]. Fixes problems with jdk 1.5 and jdk 1.4. testresources (attachment 80120 [details]) have to be installed.
Created attachment 80203 [details] fix Thanks Feri, this works. Can you also provide the source of the test resource libs you've created? I guess mylib_stdout.jar can just replace mylib.jar.
Created attachment 80263 [details] source for the new libs mylib_stdout.zip and mylib_sig.zip
I have to move this, I'm still awaiting legal approval.
Created attachment 83768 [details] fix
fixed > I20071120-1300 Finally, thanks Ferenc!
.
