Re: [incquery-dev] eclipsecon example

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [incquery-dev] eclipsecon example

From: Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>
Date: Tue, 22 Oct 2013 15:03:36 +0200
Delivered-to: incquery-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/incquery-dev>
List-help: <mailto:incquery-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/incquery-dev>, <mailto:incquery-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/incquery-dev>, <mailto:incquery-dev-request@eclipse.org?subject=unsubscribe>

Hi,

good news and bad news. Tl;dr: I know what is the problem, but have no idea how to fix it efficiently.

The problem is that the XmiBuilder needs to copy EPackage URIs that fails quite badly in case of Xcore URIs.

The good solution for this problem would be the builder refactors (that will not be ready this week), as it would allow to remove the erroneous code in its entirely.

As a workaround, I have added an exception handler to suppress this issue (seems working for me, and makes also sense) in http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/commit/?id=d4bf0f1e8042b52ae5458d3cc42014335d590478

Try it out and report back please.

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.10.21., at 23:21, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:

> Hi,
> 
> I am thinking/looking at the code, and for me, this makes no sense. First of all, if the Library class is introduced in the xcoreiq file, it should not be processed, as it has no PatternModel roots; otherwise that class should not be referenced via a containment reference.
> 
> To further debug the issue, I would look at the following things:
> * The list of resources processed in the innermost for in XmiModelBuilder#build (inside the if (obj instanceof PatternModel && !obj.equals(xmiModelRoot)) {} block). I would try to see whether somehow the xcoreeiq gets through.
> * I would also check the position of the problematic Library element in the containment hierarchy. It might give an idea why the Library is getting copied.
> 
> As a final thought (by browsing the code): this seem to happen because something is not resolved. My tip would be that at some point the Library EClass cannot be found for the resolver, but have no idea why.
> 
> Tomorrow in the afternoon I will try to reproduce it (unless it gets solved in the meantime :) ).
> 
> Cheers,
> Zoli
> -- Zoltán Ujhelyi
> https://www.inf.mit.bme.hu/en/members/ujhelyiz
> 
> Fault Tolerant Systems Research Group
> Budapest University of Technology and Economics
> 
> On 2013.10.21., at 23:02, Tamas Szabo <tamas.szabo@xxxxxxxxx> wrote:
> 
>> It is the name attribute of the Library class.
>> After full clean the extensions are generated but then if I modify the eiq file again I get the same Exceptions.
>>> Hi,
>>> 
>>> can you try to use the debugger to find out attribute/feature is failing to serialize? As the exception is thrown inside a resource#save, it is very hard to guess what happens here from this trace.
>>> 
>>> Zoli
>>> -- Zoltán Ujhelyi
>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>> 
>>> Fault Tolerant Systems Research Group
>>> Budapest University of Technology and Economics
>>> 
>>> On 2013.10.21., at 22:56, Tamas Szabo <tamas.szabo@xxxxxxxxx> wrote:
>>> 
>>>> I have removed the ValidationQueries.eiq (and copied to contents to the LibraryQueries.eiq file) in order to avoid the cyclic dep problem (for now).
>>>> 
>>>> However, after every eiq file modification I get this exception which prevents the builder to write the extension definitions into the plugin.xml:
>>>> 
>>>> !ENTRY org.eclipse.incquery.patternlanguage.emf.ui 4 0 2013-10-21 22:54:51.629
>>>> !MESSAGE Exception during XMI build!
>>>> 
>>>> !STACK 0
>>>> org.eclipse.emf.common.util.WrappedException: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EAttributeImpl cannot be cast to org.eclipse.emf.ecore.EReference
>>>>   at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:107)
>>>>   at org.eclipse.emf.ecore.xcore.resource.XcoreResource.getEObject(XcoreResource.java:184)
>>>>   at org.eclipse.incquery.tooling.core.generator.util.EMFPatternURIHandler.deresolve(EMFPatternURIHandler.java:113)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.deresolve(XMLHelperImpl.java:815)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(XMLHelperImpl.java:801)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveHref(XMLSaveImpl.java:2295)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveHRefSingle(XMLSaveImpl.java:2379)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1562)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1219)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2711)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1176)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1037)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2398)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1542)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1219)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2711)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1176)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1037)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2412)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1548)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1219)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2711)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1176)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1037)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2412)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1548)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1219)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2711)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1176)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1037)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2412)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1548)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1219)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2711)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects(XMISaveImpl.java:84)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:590)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:251)
>>>>   at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:365)
>>>>   at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1430)
>>>>   at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:999)
>>>>   at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelBuilder.build(XmiModelBuilder.java:192)
>>>>   at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.internalBuild(XmiModelSupport.java:103)
>>>>   at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.build(XmiModelSupport.java:76)
>>>>   at org.eclipse.incquery.tooling.core.generator.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:140)
>>>>   at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60)
>>>>   at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:190)
>>>>   at org.eclipse.xtext.builder.impl.XtextBuilder.incrementalBuild(XtextBuilder.java:166)
>>>>   at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:95)
>>>>   at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
>>>>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>>>>   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
>>>>   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
>>>>   at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
>>>>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>>>>   at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
>>>>   at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
>>>>   at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
>>>>   at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
>>>>   at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
>>>>   at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
>>>> Caused by: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EAttributeImpl cannot be cast to org.eclipse.emf.ecore.EReference
>>>>   at org.eclipse.xtext.linking.lazy.LazyURIEncoder.resolveShortFragment(LazyURIEncoder.java:105)
>>>>   at org.eclipse.xtext.linking.lazy.LazyURIEncoder.decode(LazyURIEncoder.java:89)
>>>>   at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:95)
>>>>   ... 59 more
>>>>> Just a clarification:
>>>>> 
>>>>> On Sunday, October 20, 2013 at 7:58 AM, Istvan Rath wrote:
>>>>> 
>>>>>>> The length call still cannot be used in the check :(
>>>>>> Actually, it can be used, you will get a weird classpath error inside the Ecore editor, but it will work correctly nonetheless (in dynamic mode). Shall we disable the "Errors" tab altogether from the editor for the sake of the demo? :-)
>>>>> The error we see comes from the validation attempt of the .eiq resource that is contained in the "main" resourceset of the Reflective Editor, and can be ignored (everything works just fine as not this .eiq has been used to initialize the SettingDelegateFactory).
>>>>> 
>>>>> However, for the sake of avoiding weird questions at the demo, I'm strongly leaning towards disabling validation altogether in this editor (for the time being).
>>>>> 
>>>>> Istvan
>>>>> 
>>>>> -- 
>>>>> Istvan RATH, PhD
>>>>> Research fellow
>>>>> Budapest University of Technology and Economics
>>>>> Fault Tolerant Systems Research Group
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> incquery-dev mailing list
>>>>> incquery-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>> _______________________________________________
>>>> incquery-dev mailing list
>>>> incquery-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>> 
>> 
>> -- 
>> Tamas Szabo
>> Software engineer
>> 
>> Tel.:   +49 711 342 191 0
>> Fax.:   +49 711 342 191 29
>> Mobil:  +49 171 565 416 9
>> Web:    www.itemis.de
>> Mail:   tamas.szabo@xxxxxxxxx
>> Skype:  szabta89
>> 
>> itemis AG
>> Niederlassung Süd
>> Meitnerstr. 10
>> 70563 Stuttgart
>> 
>> Rechtlicher Hinweis:
>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>> Lünen
>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>> Pietrek | Jens Trompeter | Sebastian Neus
>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>> | Michael Neuhaus
>> 
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>

References:
- Re: [incquery-dev] eclipsecon example
  - From: Ábel Hegedüs
- Re: [incquery-dev] eclipsecon example
  - From: Istvan Rath
- Re: [incquery-dev] eclipsecon example
  - From: Tamas Szabo
- Re: [incquery-dev] eclipsecon example
  - From: Istvan Rath
- Re: [incquery-dev] eclipsecon example
  - From: Istvan Rath
- Re: [incquery-dev] eclipsecon example
  - From: Tamas Szabo
- Re: [incquery-dev] eclipsecon example
  - From: Ujhelyi Zoltán
- Re: [incquery-dev] eclipsecon example
  - From: Tamas Szabo
- Re: [incquery-dev] eclipsecon example
  - From: Ujhelyi Zoltán

Prev by Date: [incquery-dev] Fw: incquery & xcore demo for eclipsecon
Next by Date: Re: [incquery-dev] ProjectGenerationHelper.removeAllExtension
Previous by thread: Re: [incquery-dev] eclipsecon example
Next by thread: Re: [incquery-dev] eclipsecon example
Index(es):
- Date
- Thread

Breadcrumbs