| Re: [incquery-dev] eclipsecon example |
pattern emptyBook(B: Book) {
Book.title(B, T);
check((T as String).length == 0); // works well
//check(T.length == 0); // doesn't work, gives weird XMI serialization exceptions
}
pattern averageNumberOfCoauthorsPerBook(W : Writer, A) {
NumOfBooks == count find writerOfBook(_B, W);
NumOfCoAuthors == count find coAuthorsOfWriter(W, _CW);
A == eval(if (NumOfBooks == 0) 0 else NumOfCoAuthors.doubleValue / NumOfBooks.doubleValue);
}
On Monday, October 21, 2013 at 11:21 PM, Ujhelyi Zoltán 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 UjhelyiFault Tolerant Systems Research GroupBudapest University of Technology and EconomicsOn 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 UjhelyiFault Tolerant Systems Research GroupBudapest University of Technology and EconomicsOn 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 0org.eclipse.emf.common.util.WrappedException: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EAttributeImpl cannot be cast to org.eclipse.emf.ecore.EReferenceat 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.EReferenceat 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 moreJust 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, PhDResearch fellowBudapest University of Technology and EconomicsFault Tolerant Systems Research Group_______________________________________________incquery-dev mailing list_______________________________________________incquery-dev mailing list_______________________________________________incquery-dev mailing list--Tamas SzaboSoftware engineerTel.: +49 711 342 191 0Fax.: +49 711 342 191 29Mobil: +49 171 565 416 9Web: www.itemis.deMail: tamas.szabo@xxxxxxxxxSkype: szabta89itemis AGNiederlassung SüdMeitnerstr. 1070563 StuttgartRechtlicher Hinweis:Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:LünenVorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. GeorgPietrek | Jens Trompeter | Sebastian NeusAufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann| Michael Neuhaus_______________________________________________incquery-dev mailing list_______________________________________________incquery-dev mailing list