Community
Participate
Working Groups
In a plugin.xml file we can have the following syntax for the runtime section: <!ELEMENT runtime (library+)> <!ELEMENT library (export*)> <!ATTLIST library name CDATA #REQUIRED type (code | resource) "code" > <!ELEMENT export EMPTY> <!ATTLIST export name CDATA #REQUIRED > The attribute 'type' is not exposed in the PDE. It should be exposed and relevant documentation added to the PDE Guide: type – specifies whether this library contains executable code (‘code’) or just resources. If the library is of type ‘code’ accessing anything in this library will cause activation of the plug-in. Accessing a ‘resource’ will not cause plug-in activation (a potential for significant performance improvement). It should be noted that specifying a library of type 'code' allows it to contain both code and resources. But specifying a library of type 'resource' assumes the library will only be used for resources.
Last time when I checked with the core team, I was told that the importance of the type attribute has diminished and that it is rarely used. Same for 'optional' import element. By checking the manifest parser code, I found couple more 'hidden' attribute that we do not use and was told by the core team that they will not be documented and recommended for use.
The library "type" attribute has one important use: libraries that hold translated NL strings. These should always be marked "resource" so that they do not slow down the speed of loading code from plug-ins. As for unspecified attributes, these should be rooted out and either removed or spec'd. Please bring anything like this to our attention.
Do we have any plug-ins or fragments with 'type' attribute used? I checked PDE model and it has the slot for 'type', is capable of saving it back into XML but interestingly does not load it from XML :-). Is this a stop-ship?
The Eclipse project does not have any plug-ins or fragments that use the "type" attribute. It is the IBM group doing the translations that will (or rather, should) end up with some. Both problems at the core and UI needed to be fixed. Workaround: edit plugin.xml/fragment.xml in the source pane of the PDE editor (or use a different editor entirely) if you need to edit a manifest that uses the 'type' attribute of the <library> element. Not a stop-ship for 2.0; but deserves a readme.
Fixed.
