Bugzilla – Full Text Bug Listing
| Summary: | Eclipse doesn't honor Manifest.mf line length specification | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Dirk Baeumer <dirk_baeumer> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dirk Baeumer
the runtime parser tolerates lines longer than 72 chars and so does the JRE manifest parser. That is why we tolerate lines up to 512 chars. If we impose the 72 char-restriction then the manifest would be difficult to read, especially with long package names and when you factor in the directives (x-internal, x-friends, etc.) I suggest you use the plug-in export when you want to export your plug-ins. We can't be responsible for the JAR tool mangling your manifest. The question is whether it's OK to have a MANIFEST.MF which is in a JAR and which does not follow the spec. It's perfectly fine. I ran into a problem when I used an ant task to generared a jar'd version of the plug-in. The jarfile ant task massages the manifest.mf file and wraps lines at 72. These leads to jar'd plug-ins that can't be started anymore. I understand, but please use the plug-in export when jarring your plugin. Enforcing the 72-byte restriction would severely impede the legibility of the file and is unnecessary since both the runtime and the JRE manifest parser handle longer lines just fine. I think this is rather a runtime than a pde discussion: I'm not a gainst super tooling but it should still be possible to use the standard tools to generate a standard JAR manifest as defined by the spec. Can you attach the standard manifest that causes runtime a problem? We will have simiilar problems with the jarsigner. It munges the manifests as ewll. It is possible that we have a bug in our manifest parser that does not handle wrapped lines properly. Dirk, can you supply the manifest that was causing trouble? Created attachment 19931 [details]
The manifest that caused problems
there do not appear to be any strangely wrapped lines in that manifest. Can you supply the actual faulty manifest I don't have the file anymore and I already changed our ant scripts to use zip
instead of jar. To create it simply create a jar using the following ant task
<jar jarfile="${destjar}" manifest="META-INF/MANIFEST.MF">
<fileset dir=".">
<include name="plugin.xml" />
<include name="plugin.properties" />
<include name="icons/**"/>
</fileset>
<fileset dir="bin" />
<fileset file="${tempdir}/src.zip" />
</jar>
That generated a manifest with wrapped lines, which was still correct and run without problems for me. Dirk, are you sure the plug-in did not run due to the wrapped lines? Yes. I saw this too. For some manifest files it actually worked when wrapped but for some it did not. Dirk, can you remember which project contained that manifest? I thought it was ltk.ui, but I am not 100% sure. When I encountered this I jar'd ltk.core and jdt.ui as well. So it might have been one of these plug-ins. closing... Wassim, I still think that this is a real issue since others might get tricked as well. I don't think it is critical for 3.1 but simply closing it as works for me is strange. Then close it as won't fix ;-). it's not that there was a problem that we didn't fix or we are denying that it exists. No proof (attachment) was ever presented that the plugins did not work because the manifest.mf was mangled due to line lengths. When we tried to reproduce it, the lines were wrapped but the manifest.mf was still valid and hence the resolution is appropriate. oh, but if you are referring to the "Eclipse doesn't honor Manifest.mf line length specification". Then absolutely, this is a WONTFIX. |