Community
Participate
Working Groups
Not that bundles are going to be signed using JarFile in the plugin converter will result in a performance hit. There is no reason to use JarFile in this case. We should look to using ZipFile for RC2.
slipping to 3.3 ... bug 136662 addressed the performance concerns. Moving to ZipFile is not necessary for 3.2.
If you do use ZipFile, please make sure to properly order the manifest entry in the resulting jar file. See Bug 136810.
This bug is about jar/zip file reading not creating so there is no issue about ordering of the manifest here. The converter just reads the content of the jar file (plugin.xml, manifest.mf etc) and creates a bundle manifest for the Framework to use in place of the original manifest supplied by the bundle. It does not modify or create a jar file.
(In reply to comment #3) Then, nevermind... :-)
Just want to clarify here. If we are using JarFile and things are signed then we will get whacked no? If bug 136662 fixed the problem, why is this one not closed?
bug 136662 was a one line change to the create the JarFile with new JarFile(bundleFile, false) to indicate that the jar should not be varified. This bug is to move completely off of using JarFile and instead use ZipFile because there is no real reason for us to be using JarFile in the converter. A motivation for doing this would be to allow the plugin converter to run on OSGi/Minimum because JarFile does not exist there. To me that is low priority since this is a compatibility thing anyway and it currently runs fine on Foundation.
thanks for the clarificaiton. We could just do the change to zip fiels with no real risk right?
Created attachment 44525 [details] patch The risk is low, but the benifit is pretty low also. I will release this patch for 3.3. I don't see a need for this in 3.2.1.
Fixed for 3.3 M1. Jeff you can reopen if you feel this should be fixed in 3.2.1.