Community
Participate
Working Groups
M7 I have implemented a schema for the upcoming common expression language. Since the common expression language is used in higer level plug-ins I need the possible to import the common expression language schema accross plug-ins.
Dejan, what will happen to this bug during M9. I would appriciate to get a fix for it in the two first weeks of M9 since this will require some additional work in the expression language and JDT/UI and I don't want to do this right before the end of M9. Is this possible ?
I will revisit schema editor this week so I will take the opportunity to address this if possible.
Thanks.
The code is in and will appear in the next integration build. The solution is as follows: The support works as today for simple locations of the included schemas. However, if the 'include' element has the following form: <include schemaLocation="schema://pluginId/relativeSchemaPath"/> we will treat it by looking up plug-in with the provided pluginId, and adding the relative schema path to the location of the resolved plug-in. When parsed in during the development (in Eclipse), pluginId is resolved using plug-in model manager. This means that parent schema can be in the workspace, while external schema is outside i.e. they don't have to be colocated. When parsed during automated Eclipse build (inside the Ant task), pluginId will be resolved by assuming that all plug-ins are colocated and that the desired plug-in location can be resolved by going up one level and appending pluginId to the starting location. This is a safe assumption in the context of the Eclipse build process. I will leave this defect open to record any issues with the current implementation. Note that shared schemas (those designed for inclusion in other schemas rather than referenced from plugin.xml) should not have 'extension' element. Otherwise, they should have all the fields and documentation completed as usual. When creating a new schema from scratch, use PDE 'new schema' wizard and check the appropriate field for shared schemas (a checkbox). This will result in a schema that does not have extension element.
Thanks, will try it as soon as we have an integration build
If you want to try right away, check out org.eclipse.pde.core and org.eclipse.pde plug-ins into the workspace.
Dirk, is the added support working for you?
like a charm
Yey! Proudly closing :-).
This doesn't appear to be working. The core refactoring (ltk) schemas use this new support, but plug-ins referencing the refactoring extension point still get warnings in their plugin.xml. See org. eclipse.jdt.debug.ui/plugin.xml for an example.
Erg. The warnings have magically disappeared now. I'm not sure what that means, but I'll close this bug again. If I can reproduce the problem, I'll open a new report.
It may be that our manifest validator (builder) is not perfect in detecting interesting changes i.e. changes in projects that should cause other projects to rebuild.
I managed to reproduce the problem with warnings showing up on the refactoring extensions. They appeared after I'd edited a schema from Debug UI, which was strange. After poking around at it a while, I managed to make them go away by going to the "Target Platform" page and clicking Reload. So it looks like it had something to do with failing to pick up changes in the required plug-ins from my host. So now I'm back to just having warnings from the Debug UI extension point (launchShortcuts). I've added the appropriate <include> tag to the schema, but our extension (in JDT Debug UI) is still showing warnings. Dejan, is there any way for me to make PDE look at the schema file again and "revalidate" my plugin.xml?
Typically, modifying plugin.xml will revalidate it. Apparently we are not correctly revalidating plug-ins that contain schemas that changed. This is not a big issue when schemas are static (i.e. read only) but is an issue when you have schema in the workspace and are actively changing it.
