Community
Participate
Working Groups
The org.eclipse.core.expressions plugin isn't configured to package its .exsd files into the runtime bundle. They only get packaged into the source bundle. This is a problem because one of those schemas (expressionLanguage.exsd) is extensively imported into extension points throughout the Eclipse Ecosystem. <include schemaLocation="schema://org.eclipse.core.expressions/schema/expressionLanguage.exsd"/> The problem happens when you are working on the source of one of these importing plugins, but your target platform does not include Eclipse Platform source bundles. This causes PDE to flag your schemas with problems as it is unable to resolve schema import. Very annoying. I think that there shouldn't be an assumption that everyone coding to API of org.eclipse.core.expressions bundle should have its source bundles in their target platform. The common practice is to package .exsd files in the runtime bundle. They are part of the bundle's API. Will attach a simple patch to build.properties to fix this.
Created attachment 184835 [details] Patch v1 Attached patch moves the plugin's schema directory from source bundle to the runtime bundle. It would be great to have this considered for Indigo inclusion.
Sorry, I have to move this back to Platform/Runtime. During the ACL cleanup, I lost commit rights on org.eclipse.core.expressions, so I couldn't even commit this any more. > I think that there shouldn't be an assumption that everyone coding to API of > org.eclipse.core.expressions bundle should have its source bundles in their > target platform. The common practice is to package .exsd files in the runtime > bundle. They are part of the bundle's API. See bug 139161 comment 3 about the "commonness" of packaging .exsd files in the binary bundle. I guess the problem is that .exsd files are a mixture of - API declaration (the schema, corresponds to Java .class files) and - API documentation (corresponds to .java source files or generated Javadoc) If we change some bundles to ship the schemas with the binary bundle, then we should do this in the whole SDK.
IMHO the concerns over a little bit of extra space in runtime/binary bundles should take back seat to the pretty serious issue of being unable to code to many of platform's extension points unless platform source is also present.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
