Community
Participate
Working Groups
A huge disadvantage of XML based plugin descriptions is that there is no friendly java compiler that makes lots of syntactical and semantic checks. If there is something wrong in XML (besides XML syntax itself) it simply fails without giving a hint. I think PDE at development time and Eclipse at runtime should make a lot of semantic checks on parsing plugin.xml: o do the referenced IDs match (and even exist) o is plugin/class instanceof AbstractUIPlugin (there are really strange error messages if not), o is view/class instanceof IViewContent If there are typos like point="org.eclipse.core.runtime.producrs", neither the Extensions tab of the plugin editor complains, nor is there any error message in the log and the programmer can spend hours of searching. Other checks I can think of are O do exported libraries or referenced icons exist o does package exist in <export name="mypacke"/> And certainly there are lots of other things that can go wrong on entering XML.
Note that PDE does support some of these checks, but their reporting severity may need to be bumped up, via Window > Preferences > Plug-in Development > Compilers. There have been steady improvements in this area between Eclipse 3.0 and 3.2.
most of the checks mentioned here are already implemented. The only outstanding ones are: 1. type checking: ie. view/class instanceof IViewContent. This one is pretty reasonable and we have enough information in the schema to do so. 2. ids and id refs, such as editor ids, menu ids, etc. I don't see this one happening any time soon. This one would require changes to all schemas, as these ids are currently marked as strings. For validation, given how these ids are used, there is a lot of room for error and it would be very expensive, as we would have to keep track of all those ids.
I thought you did do (1) already (note in the example it should be IViewPart).
we only check for the presence/absence of a type. the actual check for the type hierarchy we don't do. I vaguely remember that it may have been a costly operation and that is why we don't do it. I will have to check.
Yes, my first implementation (probably suboptimal) made it the main bottleneck of the entire PDE builder.
for #2 of comment 2 is it reasonable to put this support in place for 3.2 and allow exploitation over time? We would jump on this and update our schemas the day after such support went into an I build.
I do not understand why schema changes were necessary for semantic checks. Let simply the consumers of the information contained in the plugin.xml do the semantic checks. E.g. it would suffice if the code that instantiates a view would cast the new class to IViewContent and would throw a clear and exact error message if there is a class cast exception.
There have been improvements to the PDE builder over the part four years. This bug is too general to fix. Closing as INVALID. Please open new bugs with specific issues in the current versions of Eclipse.
