Community
Participate
Working Groups
I am using the PDE Template Wizard framework to generate a new plug-in project. When using 3.3M4, the generated manifest.mf file is missing a couple of entries: * "Bundle-Localization: plugin" (the out-of-box PDE templates have this problem as well) * "Export-Package" (my extended template section updates the plugin model with a IPluginLibrary, whose content filter used to get added to the Export-Package header) Both of them used to get generated in prior PDE builds, including 3.3M3 and 3.2.x. The same problem exists regardless of having specified Eclipse version 3.2 or 3.3 for the Target Platform on the Plug-in Project wizard page.
why do you need the Bundle-Localization header to be generated by default? None of the templates provided have externalized strings.
Well, my extended template section does use externalized strings, and have included a plugin.properties file in the templates file list.
Nothing in the API that guarantees the presence of a Bundle-Localization header in the generated manifest.mf. It has been added gratuitously up until now, and we now stopped. As for an exported library, we should enumerate all exported packages, so this would be a bug. we need to look into it.
What's the preferred way to trigger the generation of the Bundle-Localization header?
Since there is no localization field in the plug-in wizard itself, there is no explicit way to trigger it. Clients cannot depend on the header being there since its value is not set in the wizard and the API does not talk about it. It may be an interesting idea for the future to have clients add arbitrary headers to the manifest.mf. But seeing that M5 is practically API freeze, this will not happen for 3.3. I suggest moving your template strings into the plugin.xml. PDE provides NLS tools anyway, so externalizing strings after project creation is an easy one-step operation (PDE Tools > Externalize strings... from the context menu of plug-in projects). No urgent need to have NLS done during the project creation phase.
Thanks for the explanation. For my use case though, the externalized strings in plugin.properties are not necessarily used for NLS only. It is also used as a convenient way to ensure the same value, e.g. an id, is assigned to multiple configuration elements in the plugin extensions. Thus I need to generate them at project creation. It would indeed be quite useful for the PDE Template API to allow an extender to specifiy own headers for the generated manifest.mf. I will submit a separate Bugzilla entry for this. In the mean time though, I'm stuck without a public API solution to trigger the generation of the Bundle-Localization header. As it stands now, I'm forced to use the internal PDE bundle API to set the header to work around this issue. Please consider resume throw in the bone for 3.3, i.e. continue to generate the Bundle-Localization header by default. Even though the original behavior is not guaranteed, it would be much more client-friendly to maintain it until a public API solution is made available. BTW, this issue impacts the bug in the Eclipse DTP and BIRT projects: https://bugs.eclipse.org/bugs/show_bug.cgi?id=172744 Separately, I'm looking forward to hearing your investigation findings on the Export-Package header issue described earlier.
"We are not monsters" - Wassim :) Implemented Wassim's suggestion. If a plugin.properties is included as a new file, then we set the Bundle-Localization header to "plugin". This should work until we can readdress the API after 3.3. Available in M6.
Brian, was the Export-Package issue addressed?
OK, I am human, I missed that part... Linda, you mention that your template adds a IPluginLibrary that contains a filter. Is this library a source folder or a binary jar? I am trying to figure out how complex I need to make the package searching.
(In reply to comment #9) Brian, The IPluginLibrary is a source folder. Thanks.
Modified NewProjectCreationOperation. If project contains libraries, we iterate through them. If a library is fully exported, we then export all the non-empty packages in the source folders. Otherwise, if a library is exported with filters, we then use these filters to build the export-package statement. Also had to slightly modify PluginLibrary.getContentFilters() because it would always return an empty array since the model did not yet have a BundleDescription. Should be 100% complete.
Brian, Thanks for the fix! Is the export-package fix applied to the M6 release end of this week? Just wondering which version I should test with...
Verified the Export-Package and Bundle-Localization header bug fix in Platform 3.3M7/RC0's integration build I20070503_0842.
