Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Is the ext. point "org.eclipse.xtext.ui.shared.sharedStateContributingModule" public API?(Xtext 2.5.0 introduces the extension point "org.eclipse.xtext.ui.shared.sharedStateContributingModule". Is this extension point intended to be used in Xtext generated UI plugins?)
icon5.gif  Is the ext. point "org.eclipse.xtext.ui.shared.sharedStateContributingModule" public API? [message #1226446] Wed, 01 January 2014 20:32 Go to next message
Torsten Juergeleit is currently offline Torsten JuergeleitFriend
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&q [message #1226716 is a reply to message #1226446] Thu, 02 January 2014 13:32 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3108
Registered: July 2009
Senior Member
Am 01.01.14 21:32, schrieb Torsten Juergeleit:
> 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

Hi,

yes, it is possible to replace the default IClasspathUriResolver by
using the newly introduced extension point. The recommended way would be
to extend the resource set's uri converter rather than replacing it.
That class is not injected because you would not have a chance to
replace the shared binding anyway.
Why did you need to change default impl JdtClasspathUriResolver?

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: Is the extension point "org.eclipse.xtext.ui.shared.sharedStateContributingModule&q [message #1226773 is a reply to message #1226716] Thu, 02 January 2014 17:20 Go to previous messageGo to next message
Torsten Juergeleit is currently offline Torsten JuergeleitFriend
Messages: 18
Registered: July 2009
Junior Member
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 here.


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 issue #25.

JdtClasspathUriResolver uses IPackageFragment.exists() which returns false for excluded classpath entries. So I overrode JdtClasspathUriResolver.findResourceInWorkspace() to use a "M2E-compatible version" of IPackageFragment.exists().

/Torsten
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 Go to previous message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3108
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
Previous Topic:Cross references not getting resolved on Clean Build
Next Topic:Import and content assist
Goto Forum:
  


Current Time: Tue Nov 24 03:40:09 GMT 2020

Powered by FUDForum. Page generated in 0.02212 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top