Community
Participate
Working Groups
Plugin.find(...) can be used to locate NL variants of non-Java resources (eg. html files). This is OK for most uses, but not for Workbench use, because the current call causes plugin activation (because you need to get a plugin object for this). Should have this call on PluginDescriptor instead. NOTES:
Will investigate post 2.0.
Re-opening.
Proposal: add the following method to IProjectDescriptor: /** * Returns a URL for the file at the given plug-in relative path. The file * is looked for in the plug-in and any of its fragments. The * <code>translate</code> parameter controls whether the file should be * sought in locale-specific subdirectories. * Returns <code>null</code> if the URL could not be computed or created. * <p> * Unlike <code>Plugin.find</code>, this method does not require the plug-in * be activated; it looks in fragments; and it can handle locale-specific * variants. * </p> * * @param filePath a plug-in relative path of a file in the plug-in * installation location, or in one of its fragments * @param translated <code>true</code> if the file may be translated and * should also be sought in locale-specific subdirectories, and * <code>false</code> if this file would never be translated or exist * in locale-specific variants * @return a URL for the given path or <code>null</code> * @see Plugin#find * @since 2.0 */ public URL find(IPath filePath, boolean translated);
This functionality has been added to IPluginDescriptor (and PluginDescriptor internally). These new find methods will not cause the plugin to be activated. Note that the find methods in Plugin have now been changed to use the ones in IPluginDescriptor/PluginDescriptor. The URL returned from find (in Plugin/IPluginDescriptor/PluginDescriptor) is no longer a platform URL but a 'real' URL that does not need to be processed through Platform.resolve(). Processing through Platform.resolve() will just cause the same URL to be returned. The decision to return non-platform URLs was made because in the Plugin.find code, a non-platform URL was returned if the thing being looked for was in a fragment directory and a platform URL was returned if it was found in a plugin directory. For consistency, non-platform URLs will be returned in all cases. Fragments do not currently support platform URLs. Another minor change - this code would look in the option root directory but not in the fragment or plugin root directory. Now, if a $<option>$ is specified, the option root directory will not be searched but the root of the plugin and any fragments will. For example: if you were looking for $nl$/plugin.properties and your default locale was en_CA the old code would have searched the following directories: <plugin root>/nl/en/CA <fragment1 root>/nl/en/CA <fragment2 root>/nl/en/CA ... <plugin root>/nl/en <fragment1 root>/nl/en <fragment2 root>/nl/en ... <plugin root>/nl <fragment1 root>/nl <fragment2 root>/nl ... The new code will search the following directories: <plugin root>/nl/en/CA <fragment1 root>/nl/en/CA <fragment2 root>/nl/en/CA ... <plugin root>/nl/en <fragment1 root>/nl/en <fragment2 root>/nl/en ... <plugin root> <fragment1 root> <fragment2 root> ... This is now consistent with where we search for jar and system library files.
