Home » Modeling » TMF (Xtext) » How should I extend WorkspaceProjectsState?
|
| Re: How should I extend WorkspaceProjectsState? [message #664280 is a reply to message #664226] |
Fri, 08 April 2011 08:55   |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
the WorkspaceProjectsState is only a thin adapter for the
WorkspaceProjectsStateHelper. Since the complicated locking and listener
stuff is solved in the base class AbstractAllContainersState, I'd
recommend to extend this one, delegate the WorkspaceProjectsStateHelper
in as we do in the WorkspaceProjectsState and add your own information
similar to what is done in the JavaProjectsState. You could even use
both the WorkspaceProjectsStateHelper and the JavaProjectsStateHelper
and add a third utility that provides additional information.
The WorkspaceProjectsState is indeed a singleton that is implemented in
a language independent manner. All languages share by default the same
state (actually the JavaProjectsState). The idea is, that you provide
another implementation for your own language if you want to (which is
intentational) but to reduce the amount of wasted memory for those
languages, that only rely on the defaults. Simply bind your own
IAllContainersState by means of overwriting
public Provider<IAllContainersState> provideIAllContainersState() {}
in your UI module.
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 08.04.11 00:19, schrieb Henrik Lindberg:
> Hi,
> I want to have the functionality providd by WorkspaceProjectsState, but
> in addition, I also want to add visibility to projects by reading a
> domain language specific manifest file (in a known location in each
> project).
>
> As the WorkspaceProjectState is a singleton, and I assume provides a
> service to all different Xtext based languages I clearly can not extend
> it as such.
>
> What is the recommended approach? I really would like to avoid
> duplicating the work already done in WorkspaceProjectsState.
>
> Should I write a delegating implementation of IAllProjectsState? i.e.
> one that delegates to the WorkspaceProjectsState obtained by:
> Provider<org.eclipse.xtext.resource.containers.IAllContainersState >
> workspaceProjectStateProvider =
> org.eclipse.xtext.ui.shared.Access.<IAllContainersState>
> provider(PPWorkspaceProjectsState.class);
>
> delegate = (WorkspaceProjectsState) workspaceProjectStateProvider.get();
>
> Now, since I need to listen for changes to projects and the special
> manifests files and I need to maintain state, I also need to provide the
> appropriate locking etc. The AbstractAllContainersState seems to be
> doing all this. Is it a good solution to inherit from it and combine
> this result with the one obtained from the delegate?
>
> Do you recommend some other approach?
>
> Regards
> - henrik
|
|
| | |
| Re: How should I extend WorkspaceProjectsState? [message #664496 is a reply to message #664326] |
Sat, 09 April 2011 22:33 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I now have an implementation that works quite well (I combine the
default helper for WorkspaceProjects with my special manifest based
helper, and validation works fine).
I do however have an issue with the clustering builder as it does not
find the "wanted resource descriptions".
I have found this binding (abbreviated class references):
public void configureIResourceDescriptionsBuilderScope(Binder binder) {
binder.bind(IResourceDescriptions.class)
..annotatedWith(Names.named(ResourceDescriptionsProvider.NAM ED_BUILDER_SCOPE)).
to(org.eclipse.xtext.builder.clustering.CurrentDescriptions. ResourceSetAware.class);
}
I understand that the AbstractGlobalScopeProvider is used by the
builder, and that this scope provider delegates to the
ResourceDescriptionsProvider which in turn gets the specific
NAMED_BUILDER_SCOPE bound IResourceDescritions class and then looks at
the resource loading options to determine from where the descriptions
should come. If it is for the builder, it gets them from
'...CurrentDescriptions.ResourceSetAware' which seems to be getting the
information from someplace else...
What I don't understand is what I should override in order to make the
builder get the resource descriptions from what I bound to
IAllContainersState.
Do I need my own copy of ResourceDescriptionsProvider? (is it tied to
the shared state provided by default to all (other) Xtext languages?).
Can I reuse the
org.eclipse.xtext.builder.clustering.CurrentDescriptions.Res ourceSetAware or
is that what I need to override/extend or mimic?
I have not yet made changes to the "headless" configuration in my dsl
project as I currently only have an IAllContainersState for the UI
scenario - is that what is causing my problem?
Regards
(from a confused)
- henrik
On 4/8/11 1:43 PM, Henrik Lindberg wrote:
> Thanks, got it!
> - henrik
> Sebastian Zarnekow<Sebastian.Zarnekow@itemis.de> wrote:
>> Hi Henrik,
>>
>> the WorkspaceProjectsState is only a thin adapter for the
>> WorkspaceProjectsStateHelper. Since the complicated locking and listener
>> stuff is solved in the base class AbstractAllContainersState, I'd
>> recommend to extend this one, delegate the WorkspaceProjectsStateHelper
>> in as we do in the WorkspaceProjectsState and add your own information
>> similar to what is done in the JavaProjectsState. You could even use both
>> the WorkspaceProjectsStateHelper and the JavaProjectsStateHelper and add
>> a third utility that provides additional information.
>>
>> The WorkspaceProjectsState is indeed a singleton that is implemented in a
>> language independent manner. All languages share by default the same
>> state (actually the JavaProjectsState). The idea is, that you provide
>> another implementation for your own language if you want to (which is
>> intentational) but to reduce the amount of wasted memory for those
>> languages, that only rely on the defaults. Simply bind your own
>> IAllContainersState by means of overwriting
>>
>> public Provider<IAllContainersState> provideIAllContainersState() {}
>> in your UI module.
>>
>> Hope that helps,
>> Sebastian
>
>
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664555 is a reply to message #664496] |
Mon, 11 April 2011 07:06 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
the IAllContainersState and the actually underlying resource
descriptions are two different things.
The IResourceDescriptions describe the complete set of files that should
be handled by the Xtext builder. That is, indexing, find references and
build notification will generally happen for resources that are
contained in the IResourceDescriptions. The containers represent a
language (and file-) specific view on this complete set of
resource(descriptions). That is, a container should usually not return a
resource description that is not contained in the IResourceDescriptions.
There are several implementations of the IResourceDescriptions interface
that interact with each other. Most important one for your use case is
the ClusteringBuilderState which is used in the builder context and
indirectly in the editor context. There is an extension point that
allows to replace the globally used ClusteringBuilderState with your own
implementation but it is generally a bad idea since all Xtext based
languages will be affected by this change.
Where do your additional descriptions come from? Are they available as
Eclipse's IResource in a project? If the IStorage2UriMapper can find
them, the builder will pick them up (see
ToBeBuiltComputer.updateProject(IProject, IProgressMonitor).
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 10.04.11 00:33, schrieb Henrik Lindberg:
> I now have an implementation that works quite well (I combine the
> default helper for WorkspaceProjects with my special manifest based
> helper, and validation works fine).
> I do however have an issue with the clustering builder as it does not
> find the "wanted resource descriptions".
>
> I have found this binding (abbreviated class references):
> public void configureIResourceDescriptionsBuilderScope(Binder binder) {
> binder.bind(IResourceDescriptions.class)
> .annotatedWith(Names.named(ResourceDescriptionsProvider.NAME D_BUILDER_SCOPE)).
>
> to(org.eclipse.xtext.builder.clustering.CurrentDescriptions. ResourceSetAware.class);
>
> }
>
> I understand that the AbstractGlobalScopeProvider is used by the
> builder, and that this scope provider delegates to the
> ResourceDescriptionsProvider which in turn gets the specific
> NAMED_BUILDER_SCOPE bound IResourceDescritions class and then looks at
> the resource loading options to determine from where the descriptions
> should come. If it is for the builder, it gets them from
> '...CurrentDescriptions.ResourceSetAware' which seems to be getting the
> information from someplace else...
>
> What I don't understand is what I should override in order to make the
> builder get the resource descriptions from what I bound to
> IAllContainersState.
>
> Do I need my own copy of ResourceDescriptionsProvider? (is it tied to
> the shared state provided by default to all (other) Xtext languages?).
>
> Can I reuse the
> org.eclipse.xtext.builder.clustering.CurrentDescriptions.Res ourceSetAware or
> is that what I need to override/extend or mimic?
>
> I have not yet made changes to the "headless" configuration in my dsl
> project as I currently only have an IAllContainersState for the UI
> scenario - is that what is causing my problem?
>
> Regards
> (from a confused)
> - henrik
>
>
>
> On 4/8/11 1:43 PM, Henrik Lindberg wrote:
>> Thanks, got it!
>> - henrik
>> Sebastian Zarnekow<Sebastian.Zarnekow@itemis.de> wrote:
>>> Hi Henrik,
>>>
>>> the WorkspaceProjectsState is only a thin adapter for the
>>> WorkspaceProjectsStateHelper. Since the complicated locking and listener
>>> stuff is solved in the base class AbstractAllContainersState, I'd
>>> recommend to extend this one, delegate the WorkspaceProjectsStateHelper
>>> in as we do in the WorkspaceProjectsState and add your own information
>>> similar to what is done in the JavaProjectsState. You could even use
>>> both
>>> the WorkspaceProjectsStateHelper and the JavaProjectsStateHelper and add
>>> a third utility that provides additional information.
>>>
>>> The WorkspaceProjectsState is indeed a singleton that is implemented
>>> in a
>>> language independent manner. All languages share by default the same
>>> state (actually the JavaProjectsState). The idea is, that you provide
>>> another implementation for your own language if you want to (which is
>>> intentational) but to reduce the amount of wasted memory for those
>>> languages, that only rely on the defaults. Simply bind your own
>>> IAllContainersState by means of overwriting
>>>
>>> public Provider<IAllContainersState> provideIAllContainersState() {}
>>> in your UI module.
>>>
>>> Hope that helps,
>>> Sebastian
>>
>>
>
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664568 is a reply to message #664555] |
Mon, 11 April 2011 07:55 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Not sure I understand yet, maybe later after looking at some more code.
My additional information comes from a file inside a projects. It is named
"Modulefile", and there is a special parser that is used to obtain
information from it. The result is a list of IProjects that are visible. It
is comparable to an osgi manifest in function (I.e dependency and version
constraints on other modules).
I added a helper that adds visibility (the way it is done for java). I want
the behavior to be the same as if the list of additional IProjects had
been listed as project references in the .project file.
- henrik
Sebastian Zarnekow <Sebastian.Zarnekow@itemis.de> wrote:
> Hi Henrik,
>
> the IAllContainersState and the actually underlying resource descriptions
> are two different things.
> The IResourceDescriptions describe the complete set of files that should
> be handled by the Xtext builder. That is, indexing, find references and
> build notification will generally happen for resources that are contained
> in the IResourceDescriptions. The containers represent a language (and
> file-) specific view on this complete set of resource(descriptions). That
> is, a container should usually not return a resource description that is
> not contained in the IResourceDescriptions.
> There are several implementations of the IResourceDescriptions interface
> that interact with each other. Most important one for your use case is the
> ClusteringBuilderState which is used in the builder context and
> indirectly in the editor context. There is an extension point that allows
> to replace the globally used ClusteringBuilderState with your own
> implementation but it is generally a bad idea since all Xtext based
> languages will be affected by this change.
> Where do your additional descriptions come from? Are they available as
> Eclipse's IResource in a project? If the IStorage2UriMapper can find
> them, the builder will pick them up (see
> ToBeBuiltComputer.updateProject(IProject, IProgressMonitor).
>
> Hope that helps,
> Sebastian
--
- henrik
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664574 is a reply to message #664568] |
Mon, 11 April 2011 08:54 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I am maybe doing it wrong at the end where I am getting the information...
In my Linker I do:
@Inject
private IResourceDescriptions index;
@Inject
private IContainer.Manager manager;
and then
EObject o = ...
QualifiedName = ... wanted name
Resource r = o.eResource();
IResourceDescription descr =
descriptionIndex.getResourceDescription(r.getURI());
for(IContainer c : manager.getVisibleContainers(descr, index)) {
for(IEObjectDescription objDesc : getFilteredByName(
c.getExportedObjectsByType(eClass), fqn, o)) {
targets.add(objDesc);
}
}
When called from builder, the result is different.
- henrik
On 4/11/11 9:55 AM, Henrik Lindberg wrote:
> Not sure I understand yet, maybe later after looking at some more code.
>
> My additional information comes from a file inside a projects. It is named
> "Modulefile", and there is a special parser that is used to obtain
> information from it. The result is a list of IProjects that are visible. It
> is comparable to an osgi manifest in function (I.e dependency and version
> constraints on other modules).
>
> I added a helper that adds visibility (the way it is done for java). I want
> the behavior to be the same as if the list of additional IProjects had
> been listed as project references in the .project file.
>
> - henrik
>
> Sebastian Zarnekow<Sebastian.Zarnekow@itemis.de> wrote:
>> Hi Henrik,
>>
>> the IAllContainersState and the actually underlying resource descriptions
>> are two different things.
>> The IResourceDescriptions describe the complete set of files that should
>> be handled by the Xtext builder. That is, indexing, find references and
>> build notification will generally happen for resources that are contained
>> in the IResourceDescriptions. The containers represent a language (and
>> file-) specific view on this complete set of resource(descriptions). That
>> is, a container should usually not return a resource description that is
>> not contained in the IResourceDescriptions.
>> There are several implementations of the IResourceDescriptions interface
>> that interact with each other. Most important one for your use case is the
>> ClusteringBuilderState which is used in the builder context and
>> indirectly in the editor context. There is an extension point that allows
>> to replace the globally used ClusteringBuilderState with your own
>> implementation but it is generally a bad idea since all Xtext based
>> languages will be affected by this change.
>> Where do your additional descriptions come from? Are they available as
>> Eclipse's IResource in a project? If the IStorage2UriMapper can find
>> them, the builder will pick them up (see
>> ToBeBuiltComputer.updateProject(IProject, IProgressMonitor).
>>
>> Hope that helps,
>> Sebastian
>
>
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664652 is a reply to message #664574] |
Mon, 11 April 2011 13:52 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
With the help of Sebastian, I got past the first hurdle.
Instead of just injecting the IResourceDescriptions index, this should
be done like this:
@Inject
org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider indexProvider;
And this gets a non guice provider that is then used to obtain the index
using:
IResourceDescriptions index =
indexProvider.getResourceDescriptions(resource);
I also learned that:
IResourceDescription descr =
index.getResourceDescription(resource.getURI());
returns null when a build clean is performed (followed by a new call
that returns an IResourceDescription).
I am still missing one piece of the puzzle, because when the logic is
invoked from the builder it is not getting the same set of visible
containers as in the non builder calls.
manager.getVisibleContainers(descr, index)
There is no difference if I obtain the manager via:
@Inject private IContainer.Manager manager;
or
@Inject
private IResourceServiceProvider resourceServiceProvider;
and than manager = resourceServiceProvider.getContainerManager();
I still see that the builder finds errors (because of lack of
visibility), but a call to "validate" from the editor gets an
IContainer.Manager that returns the visible containers that I want.
Grateful for help in figuring this part out.
Regards
- henrik
On 4/11/11 10:54 AM, Henrik Lindberg wrote:
> I am maybe doing it wrong at the end where I am getting the information...
>
> In my Linker I do:
>
> @Inject
> private IResourceDescriptions index;
>
> @Inject
> private IContainer.Manager manager;
>
> and then
> EObject o = ...
> QualifiedName = ... wanted name
> Resource r = o.eResource();
> IResourceDescription descr =
> descriptionIndex.getResourceDescription(r.getURI());
>
> for(IContainer c : manager.getVisibleContainers(descr, index)) {
> for(IEObjectDescription objDesc : getFilteredByName(
> c.getExportedObjectsByType(eClass), fqn, o)) {
> targets.add(objDesc);
> }
> }
>
> When called from builder, the result is different.
>
> - henrik
>
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664692 is a reply to message #664652] |
Mon, 11 April 2011 15:29 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Again with the help of Sebastian, I managed to get one step closer. The
issue is that when a clean build is performed the index starts out
empty, and the builder builds the projects in order of dependencies
obtained from the IProject itself.
This means, that everything contained in projects that were referenced
by dependencies in the .project files worked ok, but the dynamically
determined ones were not visible.
This also explains why some cross references worked sometimes (depending
on their name and order in the workspace).
So, nothing at all wrong with any complicated bindings, wrong index or
any of the other red herrings...
Now trying to figure out how to add things to the
ProjectDescription.getDynamicReferences() ...
- henrik
On 4/11/11 3:52 PM, Henrik Lindberg wrote:
> With the help of Sebastian, I got past the first hurdle.
> Instead of just injecting the IResourceDescriptions index, this should
> be done like this:
>
> @Inject
> org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider indexProvider;
>
> And this gets a non guice provider that is then used to obtain the index
> using:
>
> IResourceDescriptions index =
> indexProvider.getResourceDescriptions(resource);
>
> I also learned that:
> IResourceDescription descr =
> index.getResourceDescription(resource.getURI());
>
> returns null when a build clean is performed (followed by a new call
> that returns an IResourceDescription).
>
> I am still missing one piece of the puzzle, because when the logic is
> invoked from the builder it is not getting the same set of visible
> containers as in the non builder calls.
>
> manager.getVisibleContainers(descr, index)
>
> There is no difference if I obtain the manager via:
> @Inject private IContainer.Manager manager;
> or
> @Inject
> private IResourceServiceProvider resourceServiceProvider;
> and than manager = resourceServiceProvider.getContainerManager();
>
> I still see that the builder finds errors (because of lack of
> visibility), but a call to "validate" from the editor gets an
> IContainer.Manager that returns the visible containers that I want.
>
> Grateful for help in figuring this part out.
>
> Regards
> - henrik
>
> On 4/11/11 10:54 AM, Henrik Lindberg wrote:
>> I am maybe doing it wrong at the end where I am getting the
>> information...
>>
>> In my Linker I do:
>>
>> @Inject
>> private IResourceDescriptions index;
>>
>> @Inject
>> private IContainer.Manager manager;
>>
>> and then
>> EObject o = ...
>> QualifiedName = ... wanted name
>> Resource r = o.eResource();
>> IResourceDescription descr =
>> descriptionIndex.getResourceDescription(r.getURI());
>>
>> for(IContainer c : manager.getVisibleContainers(descr, index)) {
>> for(IEObjectDescription objDesc : getFilteredByName(
>> c.getExportedObjectsByType(eClass), fqn, o)) {
>> targets.add(objDesc);
>> }
>> }
>>
>> When called from builder, the result is different.
>>
>> - henrik
>>
|
|
|
| Re: How should I extend WorkspaceProjectsState? [message #664930 is a reply to message #664692] |
Tue, 12 April 2011 14:02 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Next step achieved: I am now able to set the dynamic references. I do
this by adding a nature with a builder. It reads my manifest file,
resolves the references in the manifest to projects and store them in
the IProject.getDescriptions().setDynamicReferences(listOfRefere nces).
However...
This does not seem to alter the behavior of the Xtext builder.
Now off to find where it is using this information to see if it is doing
this the right way - or if there some other problem.
- henrik
On 4/11/11 5:29 PM, Henrik Lindberg wrote:
> Again with the help of Sebastian, I managed to get one step closer. The
> issue is that when a clean build is performed the index starts out
> empty, and the builder builds the projects in order of dependencies
> obtained from the IProject itself.
>
> This means, that everything contained in projects that were referenced
> by dependencies in the .project files worked ok, but the dynamically
> determined ones were not visible.
>
> This also explains why some cross references worked sometimes (depending
> on their name and order in the workspace).
>
> So, nothing at all wrong with any complicated bindings, wrong index or
> any of the other red herrings...
>
> Now trying to figure out how to add things to the
> ProjectDescription.getDynamicReferences() ...
>
> - henrik
>
> On 4/11/11 3:52 PM, Henrik Lindberg wrote:
>> With the help of Sebastian, I got past the first hurdle.
>> Instead of just injecting the IResourceDescriptions index, this should
>> be done like this:
>>
>> @Inject
>> org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider
>> indexProvider;
>>
>> And this gets a non guice provider that is then used to obtain the index
>> using:
>>
>> IResourceDescriptions index =
>> indexProvider.getResourceDescriptions(resource);
>>
>> I also learned that:
>> IResourceDescription descr =
>> index.getResourceDescription(resource.getURI());
>>
>> returns null when a build clean is performed (followed by a new call
>> that returns an IResourceDescription).
>>
>> I am still missing one piece of the puzzle, because when the logic is
>> invoked from the builder it is not getting the same set of visible
>> containers as in the non builder calls.
>>
>> manager.getVisibleContainers(descr, index)
>>
>> There is no difference if I obtain the manager via:
>> @Inject private IContainer.Manager manager;
>> or
>> @Inject
>> private IResourceServiceProvider resourceServiceProvider;
>> and than manager = resourceServiceProvider.getContainerManager();
>>
>> I still see that the builder finds errors (because of lack of
>> visibility), but a call to "validate" from the editor gets an
>> IContainer.Manager that returns the visible containers that I want.
>>
>> Grateful for help in figuring this part out.
>>
>> Regards
>> - henrik
>>
>> On 4/11/11 10:54 AM, Henrik Lindberg wrote:
>>> I am maybe doing it wrong at the end where I am getting the
>>> information...
>>>
>>> In my Linker I do:
>>>
>>> @Inject
>>> private IResourceDescriptions index;
>>>
>>> @Inject
>>> private IContainer.Manager manager;
>>>
>>> and then
>>> EObject o = ...
>>> QualifiedName = ... wanted name
>>> Resource r = o.eResource();
>>> IResourceDescription descr =
>>> descriptionIndex.getResourceDescription(r.getURI());
>>>
>>> for(IContainer c : manager.getVisibleContainers(descr, index)) {
>>> for(IEObjectDescription objDesc : getFilteredByName(
>>> c.getExportedObjectsByType(eClass), fqn, o)) {
>>> targets.add(objDesc);
>>> }
>>> }
>>>
>>> When called from builder, the result is different.
>>>
>>> - henrik
>>>
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 12:02:03 GMT 2024
Powered by FUDForum. Page generated in 0.03919 seconds |
] 
Search
Help
Register
Login
Home
