Bugzilla – Full Text Bug Listing
| Summary: | Errors in plugin.xml of ui.team | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> | ||||
| Component: | Team | Assignee: | Michael Valenta <Michael.Valenta> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Michael.Valenta, mike.pawlowski, wassim.melhem | ||||
| Version: | 3.3 | ||||||
| Target Milestone: | 3.4 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dani Megert
The name I will fix but the other warnings appear to be a schema problem (i.e. the enablement rule is working as expected). Wassim, can you offer any insight into why the warnings are occurring and how we could fix them? Wassim, any update on this one? Since team does not provide its own PDE rules along with the project and since I've set those things to error per default I always have errors in my workspace due to team.ui. Mike, are we flagging something we should not? Just to be clear, comment 3 is meant for Mike Pawlowski, not Valenta. The min / max occurence validators are working as expected. The 7 error messages flagged on line 111 are all in fact due to one error. According to the popup menus extension point schema, the "not" element requires one child element from 7 choices: Extension point schema description: <!ELEMENT not (and | or | not | objectClass | objectState | pluginState | systemProperty)> To fix this problem, just specify one of the child element choices - say "pluginState" (because it requires no more children for itself). This situation can be confusing because of the complex nature of the common expressions extension point schema (used by popups). The "enablement" and "not" elements both require the same choice of child elements. Also, I must admit the error messages are not ideal either in this situation. It exposes an underlying validator limitation when recursively reporting choice min / max occurence violations (due to performance optimization) Please let me know if there are any further questions or confusion. The issue is that <adapt> is a valid child of <not> in the sense that, although PDE is flagging it as an error, the expression works as expected (and I don't think any of the valid children you mentioned would provide what is required). Does this mean it is an error in the schema of popupMenu extension point? Actually, I have a related question. Is there a single place where the schema for a valid expression is defined or does each consumer need to redefine it? If it is the former than perhaps this single schema needs to be fixed. Yes you are correct Michael, the related extension point schema would need to be updated to reflect that "adapt" is a valid child element of "not" (and perhaps other elements): <!ELEMENT not (and | or | not | objectClass | objectState | pluginState | systemProperty | adapt)> To answer your question in Comment #7, I think that schema is "commonExpression.exsd" from "org.eclipse.ui" which is a schema inclusion for "popupMenus.exsd" Once that is done, the warnings should vanish. Sounds like it could be 77043. We are hoping to drop our use of popupMenus in favour of the new menu story so that should get ride of the problem on our end. *** This bug has been marked as a duplicate of bug 77043 *** It doesn't look like bug 77043 gets fixed soon and the transfer name is not externalized and hence gives a warning. The attached patch sets the project settings to treat illegal elements as warnings and not as errors and it also externalizes the string. NOTE: in plugin.xml the string ends with a space. I transferred this into the properties file but in general this is a bad thing to do as it makes translation harder and the intended layout might get broken especially when it will be an RTL language. Created attachment 75420 [details]
Fix
Thanks for the patch Dani. I've released the patch. Since there is nothing we can do about bug 77043, I marking this as fixed. Also, I removed the space. Verified. Are you sure that the space wasn't used to have a space in the UI? As far as I know, the only place the text appears is in the Preferences Export dialog. I can't see how having a trailing space would help there, and, in general, using spaces to get leading or trailing space in the UI is generally a bad idea. I suspect that the space was inadvertent and I missed it when I applied the patch for the preferences transfer. |