Bugzilla – Full Text Bug Listing
| Summary: | Can not create feature/plugin pair with diff ids. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eduardo Pereira <eduardo_pereira> |
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Christophe Elek <celek> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | celek, dean.t.roberts, jeem, jeffmcaffer |
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 27051 | ||
| Bug Blocks: | |||
|
Description
Eduardo Pereira
What are the generated plugin.xml and feature.xml so I can debug the PlatformConfiguration ? I am confused here , isn't the change supposed to be in install.ini instead of feature.xml ? The original bug 27051 was to add a plugin attribute to the <feature> tag in the feature.xml. That bug report states that the parser and model were updated as requested. I think that this bug is pointing out that the PDE UI was not updated accordingly. That's just my cut on the situation. Action taken: I see 1) there is a new API IFeature.getPrimaryPluginID() that returns the primary plugin for a feature. This data is from the feature.xml 2) there is a new API : IPlatformConfiguration.IFeatureEntry.getFeaturePluginIdentifier() that returns the primary plugin of the primary feature (the one with the branding, splash screen etc etc). The data comes from install.ini I didn't change the spec for the first one. 1) I will change the spec 2) I will pass the bug to PDE UI so they can change the validator 3) PDE UI will pass it to UI so they can create the proper feature.xml 4) UI should use the proper new API in a proper new context (i.e if they have a IFeature, they should use the first one : example in about dialog. If this is the startup and they do not have any IFeature they should use the second : example in the startup) Action Taken: Changed feature.xml specification Action Plan: Pass to PDE UI That is possible. There is a blanket defect that covers the sync up of PDE UI to the changes of the feature DTD. I hava an IPlatformConfiguration.IFeatureEntry but when I tested it, it was not returning the plugin id, it was returning the feature id. (As in problem #3). Was this fixed? What should I load to test it? Then you need to change install.ini as specified in bug 27051 comment 9 <http://dev.eclipse.org/bugs/show_bug.cgi?id=27051#c9> Are you saying that there are 2 places where the feature developer has to specify the plugin id: install and feature.xml? Isn't it prone to error? The PDE wizard does not create a install.ini file in my feature. Where should I add this file in? About the comment #5 in this pr: I hava one instance of IFeatureEntry for each feature. Are you saying that getFeaturePluginIdentifier() will always return the same string? Action taken: The first time eclipse starts the primary plugin of the primary feature (the real product feature) is in install.ini. It is needed by startup to find the proper branding. Eclipse then parses the feature.xml and finds the primary plugin id for each primary feature. It stores them in platform.cfg if they are different from the feature id. The next startup, UpdateCore is not called. PlatformConfig relies on data in platfrom.cfg to finds the associated primary plugin identifier of the primary features. And you get them through the API #2 in comment #5 Comment 10: yes it is error prone. But only for one plugin.id so startup knows where to find the splashscreen Comment 11: You will get a different plugin id per primary feature. the install ini is created by the product. Make sure the feature you created are primary. Primary Plugin Identifier are for primary feature only. If this doesn't help, please release your code, I will debug I talked to Eduardo. We need to solve an issue. Only primary feature need a primary plugin. But UI code fetches its information (label, provider and version) from the associated plugin. I believe UI should get the list of feature from IPlatformConfiguration. Then parse the associated feature.xml to get the Label, Provider and Version. If the feature is primary, UI will need an image. In which case UI should ask for the plugin that carries the branding (primary plugin) and get the image from there. Unless I missed something, can Jeff or releng confirm we need to fix it so Eclipse will ship one primary plugin (or 3 Platform/JDT/PDE) instead of one per feature ? We already have a defect that covers the sync up of PDE UI with the latest Update spec. Can you move this defect into the appropriate inbox depending on the other issues discussed in it (not PDE)? Can Releng confirm comment 13? We want to ship eclipse with a limited amount of primary features. I have asked Jim to comment on #13 Re: comment 13 Eclipse 2.0 has exactly one primary feature: org.eclipse.platform. None of the other features are consider primary. The primary feature has its own plug-in. Most interesting information comes from the plugin.xml to allow for after-the- fact NL translation via fragments (whereas information in the feature.xml only supports pre-canned translations). In 2.0.2 I can see most feature have a primary plugin which contains Welcome.html (example: org.eclipse.jdt_2.0.2, org.eclipse.pde_2.0.2) So i seems other features are using primary plugin. I thought we wanted to reduce the number of 'primary plugin' or at least be able to specify a primary plugin instead of relying on having the same id and same version. Now, We are in a situation where UI expects an associated plugin for each feature (to retrieve identifer, version and other) where the update spec specifies (as Jim noticed) that only primary feature should have primary plugin. My questions, then, are: 1) is my understanding correct. No Other feature but primary feature should have an associated plugin (called primary plugin)? 2) if so , do we all agree there will be only one primary feature and one primary plugin in eclipse 2.1 ? 3) if so, can UI retrieve all the info from the feature.xml only (for about dialog) 4) and then what about Welcome.html file ? Isn't UI looking in the 'primary plugin' of 'NON primary feature' to retrieve such info ? the final point will be. Do we change the spec so primary plugin are allowed to non primary feaure, or should we change UI so it retrieves About Dialog or other info through other means and ways ? Ping Jim for question #1 and #2 and UI team for #3 and #4 I find the terminology confusing. Let's not call them "primary plug-ins". They're called "feature plug-ins". I didn't say or imply that "only primary feature should have primary plug-in". Any feature can be marked as primary or not. That has nothing to do with anything else. Every feature has an associated feature plug-in, from which it gets certain info. In 2.0, the id of the feature plug-in always had the same id as the feature. In 2.1, we allow a feature plug-in to have a name different from the feature id. This is bug 27051. There are other activities under way that many see changes the set of features and associated feature plug-ins for 2.1. What these activities end up coming up with should have no direct bearing on anything else. I think it would be best if some would clearly restate any open issues with this (PDE) bug. If there are issues with other components, open separate bugs and set up the appropriate dependencies. Thanks Jim, Any feature may have a feature plugin. The bug is now under Update Core for fix the code. Action taken: implemented. What does "implemented" means? Does it mean you fixed getFeaturePluginIdentifier(). Yes, it means every feature can now have an associated feature plugin. Before, the code was only allowing Primary Feature. Release in next Integration Build. (0128) What do I have to load to test the UI side? update.core I reassigned the bug to you for the UI test Loaded update core. It does not seem to work.
First problem: I added several breakpoint but the VM would not stop in any one
of them as if I was not running the code loaded in my workspace. I deleted
the .config directory and the breakpoint started working.
Second problem: Once I could debug, I added a breakpoint after the lines:
IPlatformConfiguration platformConfiguration =
BootLoader.getCurrentPlatformConfiguration();
IPlatformConfiguration.IFeatureEntry[] features =
platformConfiguration.getConfiguredFeatureEntries();
But features is always an array length 1. The only feature it is returning is
org.eclipse.platform.
The PDE launcher has changed, make sure you can see all the features in the about dialog, otherwise, test outside, in a real environemnt. We are on the edge of PDE support <g>. I am implementing/changing the about dialog. I will test it outside. Should I open another PR about this? Shouldn't I be able to develop features while self hosting? I tried it in the build from last nigth and it did not work. All features except the one that has a diff id are shown in the about dialog. Have you tried IFeatureEntry.getFeaturePluginIdentifier()? Could you add the steps I need to do to create a feature (self hosting) so I can test this. Should I move this back to update? Eduardo try update core from HEAD. Seems the release failed yesterday I have tried HEAD when self hosting and it did not work. Could you explain all the steps (starting from creating the feature) that you used to test getFeaturePluginIdentifier() so I can do the same thing. I just want to make sure that the About dialog works when the feature and plugin do not have the same id. Question: Are features suposed to work in a self host environment? As a user (a plugin developer), should I be able to create a new feature using wizard, then start the workbench and see the changes in the about dialog? It is not clear to me what are the steps to develop a new feature which makes it difficult to test it. Contacted Eduardo. When we did that together it worked fine. I will wait until next integration build and test it there. Close |