Bugzilla – Full Text Bug Listing
| Summary: | Importing a plug-in as binary project should not extract the source bundle | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Markus Keller <markus.kell.r> | ||||||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | caniszczyk, curtis.windatt.public, daniel_megert, darin.eclipse, zhumx | ||||||||||
| Version: | 3.4.1 | ||||||||||||
| Target Milestone: | 3.5 M4 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 252256 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Markus Keller
Curtis? In theory this could work and would simplify the basic binary import code. Rather than worrying about extracting the right things from the source bundle, we could just copy the whole thing. I'll try it out in M4 and we can see what problems arise. Looks like a step in the right direction, works for most cases. However, PDE is doing some funky things in the classpath creation code, expecting the source for each library to be in a separate location with a specific name. Created attachment 117150 [details]
Work in progress
This bug has expanded into a complete refactoring of the import operation. This patch isn't complete, however, binary import is now working quite well and I am seeing huge performance increases (1/5 of the time to import all of the platform plug-ins).
Created attachment 117151 [details]
mylyn/context/zip
Created attachment 117958 [details]
Work in progress II
Still a few outstanding issues to resolve.
One question for Markus, a while back you filed a bug that Wassim fixed asking for schema file to be imported as part of the operation? Is this really necessary for binary plug-ins? For source plug-ins I'm importing them, but binary plug-ins are intended to be edited, and the schema files will be available to PDE via the target platform source locations anyways.
The schema files help because it is much easier to open the schema viewer than opening help, navigating to the right location and then open the extension point documentation. And, I am now used to have them. No longer importing them would be a regression. (In reply to comment #7) +1. AFAIK, nothing has changed that would render the arguments from bug 139161 invalid. (In reply to comment #7) > The schema files help because it is much easier to open the schema viewer than > opening help, navigating to the right location and then open the extension > point documentation. > And, I am now used to have them. No longer importing them would be a > regression. Normally, when developers need extension point doc they are contributing an extension. The "Show extension point description" links to the extension point docs in the manifest editor still work. I don't think we should keep the extension docs in the workspace - they are not inteded to be edited/read/browsed for manually (i.e. vai ctrl-shift-R, or whatever) - they are part of the help/documentation and they can be accessed consistently in this manor. Is there some other reason you need to the docs? >Is there some other reason you need to the docs?
I'm just used to see those files in the Package Explorer and being able to directly see the doc. It's just handy and easy to use. Since it works in 3.4 why can't it be preserved?
The problem with the generated docs is that they are outside the IDE. When I read an extension point description, I often want to see who else references the extension point. From the schema file, I can easily search for references via the context menu. From the docs, I have to take a detour through the clipboard and the PDE search dialog. Since this is how it worked in the past, I am willing to leave it as so (otherwise people call it a regression instead of a bug fix). However, I don't agree with the approach - this is a *binary* import - it should not contain source files. I believe a *source* import should be used for this scenario. Well, I can also see and even modify the plugin.xml of a binary imported plug-in which is also very very handy sometimes, but don't worry I won't ask for the schema to be editable ;-) *** Bug 169366 has been marked as a duplicate of this bug. *** As a note, the title of this bug is "Importing a plug-in as binary project should not extract the source bundle". To get the schemas, we are going to have to extract the source bundle (though we will not extract the java source files). Planning on committing the code tomorrow. *** Bug 242341 has been marked as a duplicate of this bug. *** Fixed in HEAD, please give things a try and let us know of any problems. It appears that the move to pde/ui, my commit rights to the test bundle have evaporated. Hopefully they will be able to fix it shortly (bug 255805), but if not, I will attach a patch and hopefully Chris will have an opportunity to commit. Created attachment 118301 [details]
Test Plugin Patch
No word from the webmasters about my commit rights.
Chris, if you have a stable internet connection, can you please commit this patch, otherwise there will be compile errors in the tests.
done.
> 20091119
|