Community
Participate
Working Groups
The default color of the reserved OSGi manifest headers is "Red/Bold", whereas the color for all other headers is "Red". It is too difficult to distinguish the two, making it harder to spot cases where to misspell a header, such as "Bundle-Classpath" when you should have typed "Bundle-ClassPath". My preference would be for the reserved OSGi manifest headers to be "Blue/Bold".
Created attachment 46560 [details] org.eclipse.pde.ui.patch I didn't notice they were red ;) This helps my red/green color blind arse.
+1 Wassim
Chris, blue does not match with anything in PDE. Lavender and Salmon are supposed to be hot this fall.
What about pink? In all seriousness, we need a friendly color :) Do we need to have a vote ;)?
It does not really matter. Just make it bold, clear and distinct from regular manifest headers. That's why I like bold blue.
What's your favorite color Tom ;)?
you guys have too much time. must be summer. FWIW I thought headers were case insenstive. Perhaps we are assigning the wrong color regardless of what the color is.
oh they're sensitive. good luck trying to run with Bundle-Classpath instead of Bundle-ClassPath.
that's strange. I was sure we have whacky code in there to make the headers case insensitive. Headers.get(key) has a comment that says, * support case-insensitivity for keys Tom?
Sorry Wassim, headers are definately case INsensitive. If bundle-classpath does not work then it is likely a "bug" in PDE in setting up the dev classpath ;-) As color goes, I like it the way it is because it matches the color for key words used in the Java editor. Can the color for key words be customized? Also, I'm seeing OSGi manifest headers show up bold. I can clearly tell they are different for regular manifest headers. Am I imagining things?
does Equinox treat them insensitively or is this a standard behavior? All colors can be customized on the Plug-in Development > Editors preference page > MANIFEST.MF syntax highlighting. I like the fact that OSGi headers are the same color as regular headers but in bold. A header is a header after all. Red is consistent with Java as Tom points out. I suggest not taking any action here wrt colors, since they are customizable, unless Chris feels otherwise about accessibility.
Tom, you've got young eyes! While you are correct that "red" and "bold red" are distinct on careful inspection, I'm more in favor of two separate colors for JAR manifest headers and bundle manifest headers that can be spotted immediately regardless of the font, screen resolution, distance from the monitor and eye capacity!
The Equinox Framework does handle the header keys case insensitively. This is standard spec'ed behavior according the the jar manifest specification. I was under the impression that this is standard behavior of the jar Manifest class as well, but we do not use that class in the framework so I could be wrong. I don't have a strong opinion either way on color of non-OSGi headers. It does make some sense to make them use just the standard text color (black) instead of the color used to highlight key words.
Two things - we need to track down this case insensitivity thing. Wassim is claiming that it doesn't work. Tom and I are claiming that it should work. PDE should be coloring as per the spec and Equinox should be running according to the spec. Who is doing what? - Given the problems I have with the eclipse.org web site I am loath to counter Simon's arguments. For the record however, I will say that for me, red and bold red are readily (haha pun!) distinguishable and that these things really are "shades of one another" (manifest header and OSGi header) so bolding is appropriate. Beyond that I am perfectly happy with flaming pink and dayglow green. It would look like angry fruit salad. (btw, I'm not keen on leaving them black)
Since the colors are customizable, we will take no action on changing defaults. They are fine. Will keep the bug open to track the case (in)sensitivity issue.
There is no room for discussion, the OSGi specification follows the jar manifest syntax which states the following for "Attributes" (which are header names) Attributes: In all cases for all sections, attributes which are not understood are ignored. Attribute names are case insensitive. Programs which generate manifest and signature files should use the cases shown in this specification however. Attribute names cannot be repeated within a section. See http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Main%20Attributes
Will look at fixing this post M2.
Was a bug ever opened on the case sensativity issue? I just spent 2 days trying to figure out why the jars in my plugin were not visible to PDE NOR the runtime. Turns out the problem was that I had Bundle-Classpath instead of Bundle-ClassPath. The PDE Manifest editor showed them as not bold and bold when I fixed the case. I also see contants in the code for Bundle-ClassPath. In debugging the code the PluginInfo object had no entries for the libraries in my plugin/bundle when the case was wrong.
An additional data point. For me, if the case-sensitivity only shows up for a plugin when it is expanded and the manifest is a loose file. I can take the exact same content, jar it up and have it work.
That is because the default for Bundle-ClassPath is . Since Bundle-ClassPath is missing this works by happy accident.
*** Bug 162583 has been marked as a duplicate of this bug. ***
We now depend on another jface text fix that I have a patch against. Once this is fixed, we should be able to handle case insensitivity. One thing we may have to do is update some of our error reporters to be case insensitive too :(
*** Bug 172045 has been marked as a duplicate of this bug. ***
Brian, I am putting this one on your plate. What is more important than syntax highlighting is that the plug-in manifest editor model treats the header names without regard to case-sensitivity (see bug 172045)
Tom, are you sure the runtime supports case insensitivity? In my target platform I have a bundle who uses "Bundle-Symbolicname" instead of "Bundle-SymbolicName". When I try to create a BundleDescription for the element, I get a BundleException. It seems that when we try to create a new BundleDescription, the StateBuilder.validateHeaders() is called. This seems to look only for the case sensitive header "Bundle-SymbolicName" and if it can't find it, throws a BundleException. I doubled checked it this result with developing a similar bundle in my workspace. Again, wrong capitalization for Bundle-SymbolicName. For this case, PDE tooling highlights the header, validates it as correct, and allows the user to modify it with the Manifest Editor. When I ran it, the bundle never showed up. With no errors or indications from the tooling or runtime, this could cause headaches for users down the road.
I just tried changing "Bundle-SymbolicName" to "Bundle-Symbolicname" for one of my plug-in projects in my workspace. Once changed, the project was no recognized by PDE as a bundle. For example, when I tried to export the projects using "File > Export > Deployable plug-ins and fragments" the project was not available to select. Also, the Equinox launch configuration no longer recognized the projects as a bundle. But the Equinox framework does not care at runtime. I used PDE to exported the bundle to a JAR with the "Bundle-SymbolicName" set correctly, unzipped the JAR, changed the manifest to "Bundle-Symbolicname" and re-zipped the JAR. I was able to install the JAR and start the bundle without problem.
Brian, when creating the state, we (PDE) read the manifest ourselves into a dictionary and send it to the runtime only if it has a Bundle-SymbolicName header. I think this is the first place where we need to relax the case of the header.
Wassim, I traced the code and was able to find the Bundle-SymbolicName if the capitalization was not correct. So far so good. Then when we call stateObjectFactory.createBundleDescription and pass the dictionary with the incorrect capitalization, a BundleException is thrown and no BundleDescription is created. I tracked the BundleException down to org.eclipse.osgi.internal.resolver.StateBuilder.validateHeaders(Dictionary manifest, boolean jreBundle), line 193. This line is executed when we look in the Dictionary for Constants.BUNDLE_SYMBOLICNAME and it returns null.
Then I suggest opening a bug against equinox and make this bug dependent on it.
You will need to implement a Map which has case insensitive keys. In the Framework the Headers class to accomplish this. One way to solve this would be to copy the manifest headers passed to org.eclipse.osgi.internal.resolver.StateBuilder.validateHeaders into a case insensitive Map like the Headers class. It is probably more appropriate to do that within the StateBuilder class instead of forcing clients of the StateObjectFactory to do it.
Created attachment 64626 [details] patch for pde.core and pde.ui Adding a patch of all the files modified just in case we run into problems and have to back out changes.
Should be fixed in 3.3M7. Copied the runtimes Headers class to create a case insensitive Dictionary element for when loading the State and create a TreeMap with a custom Comparator to store headers in a case insensitive manner.
Thank you, Brian.
That was a lot of work. Thanks Brian.
Brian, can you describe the solution? I was leaning toward a fix in StateObjectFactory. I gather you came up with a fix outside the Framework.
Nevermind, I did not see comment 32 with Brians description. Still not sure that is the right thing to do. Brian please open a bug against Framework so we can think about fixing that in the framework in the future. Unless you need a case-insensitive Map for other reasons ...
Tom, we needed to do something as drastic as what Brian did for handling headers in the manifest editors, where we don't use State stuff.
