 Is the ext. point "org.eclipse.xtext.ui.shared.sharedStateContributingModule" public API? [message #1226446] |
Wed, 01 January 2014 20:32  |
 Torsten Juergeleit
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
In Xtext 2.5.0 the extension point "org.eclipse.xtext.ui.shared.sharedStateContributingModule" was introduced.
By using this extension point I was able to tweak the XtextResourceSet in an Xtext generated UI plugin (replacing the "official" JdtClasspathUriResolver with my own IClasspathUriResolver implementation).
Now I'm wondering if this extension point is considered as public API?
If yes, is it officially supported for this kind of "hackery"?
If no, is there any other supported way of modifying the instance of IClasspathUriResolver in the XtextResourceSet?
Btw. why is the JdtClasspathUriResolver "hard-coded" in JavaProjectResourceSetInitializer and not injected?
/Torsten
[Updated on: Wed, 01 January 2014 20:34] Report message to a moderator |
|
|
|
|
| Re: Is the extension point "org.eclipse.xtext.ui.shared.sharedStateContributingModule&a [message #1228306 is a reply to message #1226773] |
Mon, 06 January 2014 23:15  |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Thorsten,
the extension point cannot be used to replace an existing binding (in
the sense of a guice binding). What you can do is basically replacing a
contribution of another extension by manipulating e.g. the resource set.
This is not the intentional use case and the order is currently not
guaranteed. Please feel free to file an enhancement request with a
concrete description of your use case. Maybe there are other ways to
achieve that?
Best regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 02.01.14 18:20, schrieb Torsten Juergeleit:
> Hi Sebastian,
>
> Sebastian Zarnekow wrote on Thu, 02 January 2014 08:32
>> yes, it is possible to replace the default IClasspathUriResolver by
>> using the newly introduced extension point.
>
>
> That's good to know.
>
> Btw is there any order the modules contributed via this extension point
> are handled by SharedStateContribution?
> Because if the extension point is used to replace an existing binding
> (like I did) then this contribution must be executed after the original
> contribution.
>
>
> Sebastian Zarnekow wrote on Thu, 02 January 2014 08:32
>> The recommended way would be to extend the resource set's uri
>> converter rather than replacing it.
>
>
> Yes, that's what I did
> https://github.com/sculptor/sculptor/commit/79538565e36bae4737b007aaa2a1153ea0d2df5f#diff-213d2cfe5110b0818e8ac646c25fb92cR53.
>
>
>
> Sebastian Zarnekow wrote on Thu, 02 January 2014 08:32
>> Why did you need to change default impl JdtClasspathUriResolver?
>
>
> This was due to an issue with the M2E Eclipse plugin and Maven project
> resource folders excluded from JDTs classpath as described in
> https://github.com/sculptor/sculptor/issues/25.
>
> JdtClasspathUriResolver uses IPackageFragment.exists() which returns
> false for excluded classpath entries. So I
> https://github.com/sculptor/sculptor/blob/develop/sculptor-eclipse/org.sculptor.dsl.ui/src/org/sculptor/dsl/ui/resource/MavenClasspathUriResolver.java#L63
> to use a "M2E-compatible version" of IPackageFragment.exists().
>
> /Torsten
|
|
|
Powered by
FUDForum. Page generated in 0.02814 seconds
] 
Search
Help
Register
Login
Home
