Home » Modeling » TMF (Xtext) » Exception implementing refactoring
|
| Re: Exception implementing refactoring [message #811406 is a reply to message #810996] |
Fri, 02 March 2012 09:57   |
 Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
If all objects are within the same document, I'd rather reuse the
IXtextDocument.modify() mechanism. It will automatically reserialize the
changed parts.
If that's not an option, I see two possible reasons for the experienced
error:
1) Your model changes are incomplete, i.e. there is no valid textual
representation the manually changed model could be parsed from. This
typically comes from missing references or attributes which are
mandatory in your grammar.
2) Your model is inconsistent when you call the serializer, i.e. some
elements have already been renamed and are referred using their old
name. You will have a pretty hard time figuring out how to make this right.
Refactoring is really more complicated than most people expect. I was
very surprised about the plethora of unexpected obstacles when
implementing the rename refactoring. If yours is similar to a rename
refactoring, you could also try to reuse the renema refactoring
infrastructure.
Am 01.03.12 20:58, schrieb Lucy Sakhnenko:
> Hi,
>
> I'm implementing a very naive refactoring. I get the list of objects I
> want to change and their modifications, then, I do something like:
>
>
> options = new HashMap();
>
> SaveOptions.defaultOptions().addTo(options);
>
> SaveOptions so = SaveOptions.newBuilder().format().getOptions();
> xr.save(options);
>
>
> I thought everything was going well, until a try with a large project
> and I got this exception:
>
>
>
> Caused by: java.lang.RuntimeException: No EObjectDescription could be
> found in Scope IndexColumn.indexColumn for Column
> Semantic Object:
> Table'WFUsrPref'.table->TableStructure.indexes[3]->Index.indexcolumns[1]->IndexColumn
>
> at
> org.eclipse.xtext.serializer.diagnostic.ISerializationDiagnostic$ExceptionThrowingAcceptor.accept(ISerializationDiagnostic.java:66)
>
> at
> org.eclipse.xtext.serializer.tokens.CrossReferenceSerializer.getCrossReferenceNameFromScope(CrossReferenceSerializer.java:143)
>
> at
> org.eclipse.xtext.serializer.tokens.CrossReferenceSerializer.serializeCrossRef(CrossReferenceSerializer.java:116)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptSemantic(GenericSemanticSequencer.java:634)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$AllocationValue.accept(GenericSemanticSequencer.java:98)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$GroupAllocation.accept(GenericSemanticSequencer.java:195)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.createSequence(GenericSemanticSequencer.java:774)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.sequence_IndexColumn_IndexColumn(AbstractAGSemanticSequencer.java:3316)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.createSequence(AbstractAGSemanticSequencer.java:703)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptEObjectRuleCall(GenericSemanticSequencer.java:609)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptSemantic(GenericSemanticSequencer.java:620)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$AllocationValue.accept(GenericSemanticSequencer.java:98)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$GroupAllocation.accept(GenericSemanticSequencer.java:195)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.createSequence(GenericSemanticSequencer.java:774)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.sequence_Index_Index(AbstractAGSemanticSequencer.java:3330)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.createSequence(AbstractAGSemanticSequencer.java:697)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptEObjectRuleCall(GenericSemanticSequencer.java:609)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptSemantic(GenericSemanticSequencer.java:620)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$AllocationValue.accept(GenericSemanticSequencer.java:98)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$GroupAllocation.accept(GenericSemanticSequencer.java:195)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.createSequence(GenericSemanticSequencer.java:774)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.sequence_TableStructure_TableStructure(AbstractAGSemanticSequencer.java:5192)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.createSequence(AbstractAGSemanticSequencer.java:1237)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptEObjectRuleCall(GenericSemanticSequencer.java:609)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.acceptSemantic(GenericSemanticSequencer.java:620)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$AllocationValue.accept(GenericSemanticSequencer.java:98)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$GroupAllocation.accept(GenericSemanticSequencer.java:195)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer$Quantity.accept(GenericSemanticSequencer.java:348)
>
> at
> org.eclipse.xtext.serializer.sequencer.GenericSemanticSequencer.createSequence(GenericSemanticSequencer.java:774)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.sequence_Table_Table(AbstractAGSemanticSequencer.java:5206)
>
> at
> org.xtext.myProject.serializer.AbstractAGSemanticSequencer.createSequence(AbstractAGSemanticSequencer.java:1231)
>
> at
> org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:68)
> at
> org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:80)
> at
> org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:95)
> at org.eclipse.xtext.resource.XtextResource.doSave(XtextResource.java:286)
> at
> org.xtext.myProject.linking.MyProjectLinkingResource.doSave(MyProjectLinkingResource.java:59)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1406)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
>
> at
> myProject.ui.model.NormalizationRefactoringStartegy.refactorTables(NormalizationRefactoringStartegy.java:126)
>
> at
> myProject.plugin.popup.actions.ActionbuttonNormalize$1$2.run(ActionbuttonNormalize.java:211)
>
> at
> org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:164)
>
> at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
>
> ... 23 more
>
>
>
>
> What method should I use to serialize my new objects?
>
> Thanks
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
| |
| Re: Exception implementing refactoring [message #870045 is a reply to message #866071] |
Sat, 05 May 2012 23:20 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
> Could you identify that part of the refactoring that is responsible for
> grouping a set of changes in different files into a consistent operation?
>
> That would be a real treat!
We use the LTK API, so the result of a refactoring is a Change (usually
composite). The component for collecting all changes is the
IRefactoringUpdateAcceptor. I am not sure if that helps you ;-) I
described the basic concepts of Xtext's rename refactoring in a blogpost
last year
http://koehnlein.blogspot.de/2011/06/rename-refactoring-in-xtext-20.html
which is still valid.
> The resolved model in Xtext corresponds only to a resolved AST in the
> JDT (with serialization corresponding to an ASTFlattener). AST rewriting
> is a different (cool!) story: how to programmatically create
> modifications with minimal layout changes in the text file.
AFAIK, JDT is different from Xtext as its AST model is usually not
linked by real cross references. E.g. there is no IType.getSuperType()
but only an IType.getSuperTypeName(). In Xtext, that kind of textual
cross-reference information is only available in the node model, which
we decided to be only writable by the parser.
> From my experiments it seems that IXtextDocument.modify() limits the
> serialization to a changed covering AST node, which is a good step
> towards layout-preserving AST rewriting, but that seems to be limited to
> one document.
Did not exactly get what you mean. The modify operation collects all
semantic changes and re-serializes the AST below their common root node
trying to preserve existing whitespaces. Yes, it is limited to a single
document (resource).
> What mechanism can be used for achieving similar results across
> documents? Can explicit use of ResourceSets help? How, how would that
> integrate with XtextDocuments?
You can load all participanting models in a "refactoring" into the same
reosurce set, apply all changes on the (semantic/AST) EMF level and save
them. Finding out which files are participating can already be a
challenge... This is where al the fun about refactoring starts.
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Exception implementing refactoring [message #870370 is a reply to message #870045] |
Mon, 07 May 2012 20:25 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Jan,
thanks for your hints.
Jan Kohnlein wrote on Sun, 06 May 2012 01:20
We use the LTK API, so the result of a refactoring is a Change (usually
composite). The component for collecting all changes is the
IRefactoringUpdateAcceptor. I am not sure if that helps you 
Well, I can see how RefactoringUpdateAcceptor.createCompositeChange(..) combines several edits/changes into one big Change.
For a refactoring this looks manageable. However, I'd like to do something similar within a quickfix (forgot to mention in my previous post). I can't see how the approach can be used for a quickfix. Maybe it can't be, right?
Jan Kohnlein wrote on Sun, 06 May 2012 01:20
> The resolved model in Xtext corresponds only to a resolved AST in the
> JDT (with serialization corresponding to an ASTFlattener). AST rewriting
> is a different (cool!) story: how to programmatically create
> modifications with minimal layout changes in the text file.
AFAIK, JDT is different from Xtext as its AST model is usually not
linked by real cross references. E.g. there is no IType.getSuperType()
but only an IType.getSuperTypeName(). In Xtext, that kind of textual
cross-reference information is only available in the node model, which
we decided to be only writable by the parser.
Right, so JDT's AST kind-of corresponds to Xtext's node model, whereas the JDT creates cross-references only among bindings (which are attached to the AST, if resolved AST is requested).
Experience with implementing refactorings and similar operations in the JDT showed that a resolved AST is just what you need. Without the ability to perform rewriting on Xtext's node model I'm afraid things will be tremendously more difficult on the long run.
Jan Kohnlein wrote on Sun, 06 May 2012 01:20
> From my experiments it seems that IXtextDocument.modify() limits the
> serialization to a changed covering AST node, which is a good step
> towards layout-preserving AST rewriting, but that seems to be limited to
> one document.
Did not exactly get what you mean. The modify operation collects all
semantic changes and re-serializes the AST below their common root node
trying to preserve existing whitespaces. Yes, it is limited to a single
document (resource).
Let's pretend the DSL would be Java: when my operation adds or removes a field, the class is marked as damaged and re-serialized, right?
By contrast, the JDT's rewriter will detect the exact change and only touch the line of the field itself, leaving the layout of the rest of the class unchanged.
From my experience, Xtext fails to preserve the layout of the element that encloses the change.
Jan Kohnlein wrote on Sun, 06 May 2012 01:20
You can load all participanting models in a "refactoring" into the same
reosurce set, apply all changes on the (semantic/AST) EMF level and save
them. Finding out which files are participating can already be a
challenge... This is where al the fun about refactoring starts.
Im not worried about finding affected files, as you say that's the fun part 
What I'm clueless about is, how I could implement refactoring-like operations that affect multiple files in a quickfix. S.t. makes me feel that Xtext's quickfix infrastructure may be hiding too much, actually, preventing me from applying the strategy that works fine for refactoring.
Please tell me, I'm wrong
cheers,
Stephan
|
|
|
| Re: Exception implementing refactoring [message #870382 is a reply to message #870370] |
Mon, 07 May 2012 21:18 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Hi Stephan
>> We use the LTK API, so the result of a refactoring is a Change
>> (usually composite). The component for collecting all changes is the
>> IRefactoringUpdateAcceptor. I am not sure if that helps you ;)
>
>
> Well, I can see how RefactoringUpdateAcceptor.createCompositeChange(..)
> combines several edits/changes into one big Change.
> For a refactoring this looks manageable. However, I'd like to do
> something similar within a quickfix (forgot to mention in my previous
> post). I can't see how the approach can be used for a quickfix. Maybe it
> can't be, right?
Well, it could be, if you manage to base your quickfix on LTK Changes.
>> > The resolved model in Xtext corresponds only to a resolved
AST in the
>> > JDT (with serialization corresponding to an ASTFlattener). AST
>> rewriting
>> > is a different (cool!) story: how to programmatically create
>> > modifications with minimal layout changes in the text file.
>>
>> AFAIK, JDT is different from Xtext as its AST model is usually not
>> linked by real cross references. E.g. there is no IType.getSuperType()
>> but only an IType.getSuperTypeName(). In Xtext, that kind of textual
>> cross-reference information is only available in the node model, which
>> we decided to be only writable by the parser.
>
>
> Right, so JDT's AST kind-of corresponds to Xtext's node model, whereas
> the JDT creates cross-references only among bindings (which are attached
> to the AST, if resolved AST is requested).
>
> Experience with implementing refactorings and similar operations in the
> JDT showed that a resolved AST is just what you need. Without the
> ability to perform rewriting on Xtext's node model I'm afraid things
> will be tremendously more difficult on the long run.
Maybe this is why things already *are* quite difficult. I am pretty sure
we will not change the node model write policy within short term, as it
is one of the few really fundamental design decisions in Xtext. OTOH, I
cannot say I am very convinced of JDT's refactorings. I have the
impression that what one would really need to write any reliable
refactoring easily may be something different from both approaches :-(
>> > From my experiments it seems that IXtextDocument.modify() limits the
>> > serialization to a changed covering AST node, which is a good step
>> > towards layout-preserving AST rewriting, but that seems to be
>> limited to
>> > one document.
>>
>> Did not exactly get what you mean. The modify operation collects all
>> semantic changes and re-serializes the AST below their common root
>> node trying to preserve existing whitespaces. Yes, it is limited to a
>> single document (resource).
>
> Let's pretend the DSL would be Java: when my operation adds or removes a
> field, the class is marked as damaged and re-serialized, right?
Only the "damaged" parts, and the serializer takes existing whitespaces
into account.
> By contrast, the JDT's rewriter will detect the exact change and only
> touch the line of the field itself, leaving the layout of the rest of
> the class unchanged.
> From my experience, Xtext fails to preserve the layout of the element
> that encloses the change.
JDT has the big advantage to know what the AST is like and which
sections of it may be affected by changes. We cannot do the same in a
generic framework like Xtext. What we do is to detect the affected
subtree and try to reserialize this one. What you have experienced could
be a weak point of the old serializer infrastructure or a best effort of
a generic approach. Maybe you could you file some examples in bugzilla?
>> You can load all participanting models in a "refactoring" into the
>> same reosurce set, apply all changes on the (semantic/AST) EMF level
>> and save them. Finding out which files are participating can already
>> be a challenge... This is where al the fun about refactoring starts.
>
>
> Im not worried about finding affected files, as you say that's the fun
> part :)
It's not the fun part, but it's the first challenge in a generic
cross-language refactoring. You don't even know if the actual
declaration is in the language you started the refactoring from. Having
EMF counterparts for Java elements makes it even more 'fun'.
> What I'm clueless about is, how I could implement refactoring-like
> operations that affect multiple files in a quickfix. S.t. makes me feel
> that Xtext's quickfix infrastructure may be hiding too much, actually,
> preventing me from applying the strategy that works fine for refactoring.
As things are much more complex than expected, we decided to get rename
refactoring working at all in the first place. Having reusable parts for
other usecases such as quickfixes has not really been addressed so far.
Looking at the problems we solved so far and the complicated
architecture that was necessary to integrate with JDT, which uses it's
own internal funny abstractions below the LTK interfaces, I guess this
will still take some time.
I agree that our quickfix API is hiding a lot. It's major purpose was to
make writing simple quickfixes for DSLs as easy as possible. OOTB it is
only affecting a single resource. If you don't like it, you can still
bind your own implementation above Xtext's QuickfixProvider API.
> Please tell me, I'm wrong :)
There's a bit of truth in everything :-)
Regards
Jan
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:03:02 GMT 2024
Powered by FUDForum. Page generated in 0.03617 seconds |
] 
Search
Help
Register
Login
Home
