Bugzilla – Full Text Bug Listing
| Summary: | Enhance PluginConverter API | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Wassim Melhem <wassim.melhem> | ||||||
| Component: | Runtime | Assignee: | Thomas Watson <tjwatson> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | pascal | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.1 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Wassim Melhem
The analyseJar option is badly named since the Converter is able to generate manifests from the class files (this is how we run in self host mode). To make this support fully works, we need to provide you a way to specify in which folders the binary needs to be looked up since by default we are using the dev classpath info of the running eclipse. Although I don't see any problem in adding this support, I'm wondering why you simply do not delete the manifest from the caches so runtime will only regenerate this one. Note as well that initially the "analyseJars" parameter has been introduced to prevent require info generation so that PDE could easily generate them since it has access to the java model. By curiosity, why is this not the model anymore? "analyzeJARs" was introduced so that PDE does not pay the price of cracking all the JARs open when resolving the target platform since we don't need that information and it was an expensive operation. When generating a manifest.mf for the runtime's use upon launching, it is better to use the runtime facilities and keep PDE out of the manifest generating business. This, in fact, would be better from a runtime point of view as your code becomes heavily tested in the PDE-controlled environment. Deleting the manifest from the runtime cache never occurred to me. It would actually be easier for PDE if we deleted it. So if you want to do it that way, then fine by me. This option also exercises the runtime code for generating manifests and leaves PDE out of it, which is a good thing. The context for this request has changed but the functionality is still needed. When converting a plugin to use a manifest.mf (as we help people migrate or generate a manifest.mf using the plugin editor), we want the plugin converter to go through the bin folder and generate the export-package header. So an argument on the converter taking a dev.properties file or the like, telling you where to find the *.classes for this plugin, would be good. Created attachment 18372 [details]
Proposed solution
This patch addes a new param to convertManifest to pass a Dictionary of
development time classpaths mapping plugin ids -> a list of development paths.
I will take ownership of the defect to release the patch. Pascal, if you get a chance can you review the patch. Just to make sure, you support absolute paths, right? This would be required to accomodate cases where people use linked folders/libraries. Yes, it will support the same format as the properties file that is passed to the -dev argument of eclipse. This allows you to specify absolute paths. I released the patch so Wassim can make progress this week. This does not seem to be working. You need the latest pde.core and pde.ui from HEAD that call the new API for this. 1. Create a hello world plugin WITHOUT a manifest.mf It gets generated with a fully exported library. 2. From the runtime page of the editor, click on the link to create a manifest.mf. I verified that the dictionary contains (com.example.xyz=bin), however, the resultant manifest.mf does not contain an Export-Package. Created attachment 18467 [details]
PDE patch
The PluginConverter API is expecting a File to the location of the plugin
project. PDE is passing the location to the plugin.xml/fragment.xml in the
plugin project. This patch is a fix to PDE.
One thing I noticed is that if auto-build is not set then the manifest will
still not contain any exports because the bin/ directory does not exist yet.
Should PDE force a project build first?
verified that if you pass in the location of the plugin project itself, the manifest.mf is generated fully and correctly. As for the autobuild-off scenario, I will force a build in that case. Closing as fixed per comment 11 |