Home » Modeling » TMF (Xtext) » Woes migrating to 2.2.1 from 2.0.1 - need help
| Woes migrating to 2.2.1 from 2.0.1 - need help [message #858055] |
Fri, 27 April 2012 01:32  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
In geppetto we have been on version 2.0.1 for some time and decided to
upgrade to 2.2.1.
Now I am facing issues regarding "build clean" and my linker not being
called. The symptoms are that problems reported by validation are
handled correctly, but problems added by the linker are not.
"Build clean" no longer seem to trigger linking of everything (it does
not hit my breakpoint). All I get is that the markers from linking
disappear, but the linker is then not called.
If I open a file, it gets validated and error markers appear. I have to
open each file to see all the errors.
In the console I sometimes see messages like this (when a file with
errors is opened):
!ENTRY org.eclipse.core.resources 4 376 2012-04-27 02:12:45.951
!MESSAGE Marker id 224733 not found.
I debugged and found that in 2.0.1 I received two calls to the linker
when doing a clean - in 2.2.1 only one.
What I do in MyLinker#afterModelLinked (in a separate class) is:
@Inject
private org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider
indexProvider;
IResourceDescriptions descriptionIndex =
indexProvider.getResourceDescriptions(resource);
IResourceDescription descr =
descriptionIndex.getResourceDescription(resource.getURI());
When doing a "build clean", desc becomes null. So in 2.0.1, I just
waited for the second call, and then did the linking - if descr is null,
I just return from MyLinker#afterModelLinked.
Are there any particular things that changed that I should have taken
care of?
I also tried updating to 2.3.0, but there I found that xtext.builder and
xtext.ui requires xtext.xbase (and as a consequence many additional
depdendencies). I really don't want to include xbase since it is not
used. Should this be reported as a bug, or is the dependency on xbase
suppose to be there - if so, for what?
Regards
- henrik
|
|
|
| Re: Woes migrating to 2.2.1 from 2.0.1 - need help [message #858745 is a reply to message #858055] |
Fri, 27 April 2012 09:19  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I avoid the dependencies by having a separate 'build'; plugin for the
*.mwe2 and ... releng scripts. Worth doing even for 2.0 or 1.0.
Regards
Ed Willink
On 27/04/2012 02:32, Henrik Lindberg wrote:
> Hi,
> In geppetto we have been on version 2.0.1 for some time and decided to
> upgrade to 2.2.1.
>
> Now I am facing issues regarding "build clean" and my linker not being
> called. The symptoms are that problems reported by validation are
> handled correctly, but problems added by the linker are not.
>
> "Build clean" no longer seem to trigger linking of everything (it does
> not hit my breakpoint). All I get is that the markers from linking
> disappear, but the linker is then not called.
>
> If I open a file, it gets validated and error markers appear. I have
> to open each file to see all the errors.
> In the console I sometimes see messages like this (when a file with
> errors is opened):
> !ENTRY org.eclipse.core.resources 4 376 2012-04-27 02:12:45.951
> !MESSAGE Marker id 224733 not found.
>
>
> I debugged and found that in 2.0.1 I received two calls to the linker
> when doing a clean - in 2.2.1 only one.
>
> What I do in MyLinker#afterModelLinked (in a separate class) is:
>
> @Inject
> private org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider
> indexProvider;
>
> IResourceDescriptions descriptionIndex =
> indexProvider.getResourceDescriptions(resource);
> IResourceDescription descr =
> descriptionIndex.getResourceDescription(resource.getURI());
>
> When doing a "build clean", desc becomes null. So in 2.0.1, I just
> waited for the second call, and then did the linking - if descr is
> null, I just return from MyLinker#afterModelLinked.
>
> Are there any particular things that changed that I should have taken
> care of?
>
>
> I also tried updating to 2.3.0, but there I found that xtext.builder
> and xtext.ui requires xtext.xbase (and as a consequence many
> additional depdendencies). I really don't want to include xbase since
> it is not used. Should this be reported as a bug, or is the dependency
> on xbase suppose to be there - if so, for what?
>
> Regards
> - henrik
|
|
|
| Re: Woes migrating to 2.2.1 from 2.0.1 - need help [message #858797 is a reply to message #858055] |
Fri, 27 April 2012 09:45 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
I'm not aware of any deps to xbase itself from the xtext core bundles.
We use the xbase.lib which contains very few utilitiy classes and has no
actual dependencies. What problems did you face with that?
We loaded the resource twice in Xtext 2.0. This happens only once, now,
thus the linking is not triggered twice. You may want to checkout
LazyLinkingResource#resolveLazyCrossReferences. It may be possible to
trigger the #afterModelLinked stuff manually prior to resolving the
cross references.
If I'm not mistaken the concept of the
org.eclipse.xtext.resource.DerivedStateAwareResource may help.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 27.04.12 03:32, schrieb Henrik Lindberg:
> Hi,
> In geppetto we have been on version 2.0.1 for some time and decided to
> upgrade to 2.2.1.
>
> Now I am facing issues regarding "build clean" and my linker not being
> called. The symptoms are that problems reported by validation are
> handled correctly, but problems added by the linker are not.
>
> "Build clean" no longer seem to trigger linking of everything (it does
> not hit my breakpoint). All I get is that the markers from linking
> disappear, but the linker is then not called.
>
> If I open a file, it gets validated and error markers appear. I have to
> open each file to see all the errors.
> In the console I sometimes see messages like this (when a file with
> errors is opened):
> !ENTRY org.eclipse.core.resources 4 376 2012-04-27 02:12:45.951
> !MESSAGE Marker id 224733 not found.
>
>
> I debugged and found that in 2.0.1 I received two calls to the linker
> when doing a clean - in 2.2.1 only one.
>
> What I do in MyLinker#afterModelLinked (in a separate class) is:
>
> @Inject
> private org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider
> indexProvider;
>
> IResourceDescriptions descriptionIndex =
> indexProvider.getResourceDescriptions(resource);
> IResourceDescription descr =
> descriptionIndex.getResourceDescription(resource.getURI());
>
> When doing a "build clean", desc becomes null. So in 2.0.1, I just
> waited for the second call, and then did the linking - if descr is null,
> I just return from MyLinker#afterModelLinked.
>
> Are there any particular things that changed that I should have taken
> care of?
>
>
> I also tried updating to 2.3.0, but there I found that xtext.builder and
> xtext.ui requires xtext.xbase (and as a consequence many additional
> depdendencies). I really don't want to include xbase since it is not
> used. Should this be reported as a bug, or is the dependency on xbase
> suppose to be there - if so, for what?
>
> Regards
> - henrik
|
|
| | | | |
| Re: Woes migrating to 2.2.1 from 2.0.1 - need help [message #859414 is a reply to message #859223] |
Fri, 27 April 2012 16:19 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
CIGAR !
I changed the code - instead of doing the custom linking in
the LazyLinker#afterModelLinked, I now do it in
LazyLinkingResource#resolveLazyCrossReferences.
This is what I do:
public class PPResource extends LazyLinkingResource {
@Inject
private DocumentationAssociator documentationAssociator;
@Inject
PPResourceLinker resourceLinker;
@Override
public void resolveLazyCrossReferences(CancelIndicator mon) {
super.resolveLazyCrossReferences(mon);
final ListBasedDiagnosticConsumer diagnosticsConsumer = new
ListBasedDiagnosticConsumer();
IMessageAcceptor acceptor = new
DiagnosticConsumerBasedMessageAcceptor(diagnosticsConsumer);
EObject model = this.getParseResult().getRootASTElement();
documentationAssociator.linkDocumentation(model, acceptor);
resourceLinker.link(model, acceptor, false);
if(!isValidationDisabled()) {
getErrors().addAll(diagnosticsConsumer.getResult(Severity.ERROR));
getWarnings().addAll(diagnosticsConsumer.getResult(Severity.WARNING));
}
}
}
Do you see any problems with moving the responsibility to this class,
doing what I do above?
Regards
- henrik
On 2012-27-04 16:17, Henrik Lindberg wrote:
> On 2012-27-04 11:45, Sebastian Zarnekow wrote:
>
>> We loaded the resource twice in Xtext 2.0. This happens only once, now,
>> thus the linking is not triggered twice. You may want to checkout
>> LazyLinkingResource#resolveLazyCrossReferences. It may be possible to
>> trigger the #afterModelLinked stuff manually prior to resolving the
>> cross references.
>>
>
> So, I think you are saying - override
> LazyLinkingResource#resolveLaxyCrossReferences and then trigger my code
> that is normally triggered from #afterModelLinked.
>
> I will try that - and do like I do now and do no linking if I do not get
> a resource description (i.e. the "build clean" run).
>
>> If I'm not mistaken the concept of the
>> org.eclipse.xtext.resource.DerivedStateAwareResource may help.
>>
>
> Looked into DerivedStateAwareResource, but seems difficult to produce
> warnings and errors while producing the "derived state".
>
> - henrik
|
|
|
| Re: Woes migrating to 2.2.1 from 2.0.1 - need help [message #860042 is a reply to message #859414] |
Fri, 27 April 2012 23:05 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 2012-27-04 18:19, Henrik Lindberg wrote:
> CIGAR !
>
Actually, I got too many Cigars...
Posting what looks like the solution here, for anyone else that may
stumble on this in the future.
The LazyLinkingResource#resolveLazyCrossReferences can/will be called a
number of times - in my typical case, 4 times resulting in 4 copies of
every diagnostic.
So, to round off the implementation, I added a guard around the linking
the same way as the DerivedStateAwareResource handled the same thing.
(Too much work to actually use this Resource as it also required a
specialized ResourceDescription (I already have one that does a number
of things), and I also did not want the result to depend on someone
getting the content of the resource (I only have side effects in terms
of diagnostics).
Now, much better.
Regards
- henrik
> I changed the code - instead of doing the custom linking in the
> LazyLinker#afterModelLinked, I now do it in
> LazyLinkingResource#resolveLazyCrossReferences.
>
> This is what I do:
>
> public class PPResource extends LazyLinkingResource {
> @Inject
> private DocumentationAssociator documentationAssociator;
>
> @Inject
> PPResourceLinker resourceLinker;
>
> @Override
> public void resolveLazyCrossReferences(CancelIndicator mon) {
> super.resolveLazyCrossReferences(mon);
>
> final ListBasedDiagnosticConsumer diagnosticsConsumer = new
> ListBasedDiagnosticConsumer();
> IMessageAcceptor acceptor = new
> DiagnosticConsumerBasedMessageAcceptor(diagnosticsConsumer);
> EObject model = this.getParseResult().getRootASTElement();
> documentationAssociator.linkDocumentation(model, acceptor);
> resourceLinker.link(model, acceptor, false);
>
> if(!isValidationDisabled()) {
> getErrors().addAll(diagnosticsConsumer.getResult(Severity.ERROR));
>
> getWarnings().addAll(diagnosticsConsumer.getResult(Severity.WARNING));
> }
>
> }
> }
>
> Do you see any problems with moving the responsibility to this class,
> doing what I do above?
>
> Regards
> - henrik
>
> On 2012-27-04 16:17, Henrik Lindberg wrote:
>> On 2012-27-04 11:45, Sebastian Zarnekow wrote:
>>
>>> We loaded the resource twice in Xtext 2.0. This happens only once, now,
>>> thus the linking is not triggered twice. You may want to checkout
>>> LazyLinkingResource#resolveLazyCrossReferences. It may be possible to
>>> trigger the #afterModelLinked stuff manually prior to resolving the
>>> cross references.
>>>
>>
>> So, I think you are saying - override
>> LazyLinkingResource#resolveLaxyCrossReferences and then trigger my code
>> that is normally triggered from #afterModelLinked.
>>
>> I will try that - and do like I do now and do no linking if I do not get
>> a resource description (i.e. the "build clean" run).
>>
>>> If I'm not mistaken the concept of the
>>> org.eclipse.xtext.resource.DerivedStateAwareResource may help.
>>>
>>
>> Looked into DerivedStateAwareResource, but seems difficult to produce
>> warnings and errors while producing the "derived state".
>>
>> - henrik
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 04:35:22 GMT 2024
Powered by FUDForum. Page generated in 0.01976 seconds |
] 
Search
Help
Register
Login
Home
