Bugzilla – Full Text Bug Listing
| Summary: | Wrong package nsURI is generated into the globalEiqModel.xmi when using packages from eiqgen | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Viatra | Reporter: | Balazs Grill <balazs.grill> | ||||||
| Component: | Query | Assignee: | Zoltan Ujhelyi <zoltan.ujhelyi> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Istvan Rath <istvanrath> | ||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | abel.hegedus, balazs.grill | ||||||
| Version: | oldinquery | ||||||||
| Target Milestone: | M1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 398720 | ||||||||
| Attachments: |
|
||||||||
|
Description
Balazs Grill
This seems to be the same issue we have debugged with Abel two weeks ago. If there are multiple EPackage-s in an Ecore file, the correct calculation of the precise URI seems to be problematic (some segmens needs to be removed, but not all and not a constant amount). I will look into the issue shortly in more details. That was quite an issue. I had to reverse engineer the EMF type URI algorithm, and re-code it for our serializer extensions. It seems to be working, but some extensive testing is needed. Balázs, could you check your case whether this issue fixed it? Ábel, could you check whether I managed to fix your other test case as well? In the meantime, I am marking this issue as resolved, but feel free to re-open it if I missed something. Created attachment 226816 [details]
mylyn/context/zip
Unfortunately, the fix does not work in my case: EPackage in use: name: dungeon, nsURI: http://dungeon.jitd.descent/1.0, nsPrefix: dungeon ECore: descent \-jitd \-dungeon \-Hero Sample EClass URI at development time (before fix): http://dungeon.jitd.descent/1.0#//jitd/dungeon/Hero Sample EClass URI at development time (after fix): http://dungeon.jitd.descent/1.0#//Hero Sample EClass URI at runtime: http://dungeon.jitd.descent/1.0#//dungeon/Hero Example: https://miklosfoldenyi@bitbucket.org/miklosfoldenyi/descent.git Sorry, parent package is: name: jitd, nsUri: http://jitd.descent/1.0, prefix: jitd *** Bug 398891 has been marked as a duplicate of this bug. *** It doesn't work for me either, additionally, the builder fails with an exception in the log (apparently, there is an EClass, which doesn't have a "/" in its URI fragment. I don't know yet which is it, I'm still debugging the problem): java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Unknown Source) at org.eclipse.incquery.tooling.core.generator.util.EMFPatternURIHandler.deresolve(EMFPatternURIHandler.java:63) 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:2294) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveHRefSingle(XMLSaveImpl.java:2378) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1561) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2397) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1541) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2411) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1547) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2411) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1547) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:677) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:585) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:251) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:331) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1417) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:986) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelBuilder.build(XmiModelBuilder.java:195) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.internalBuild(XmiModelSupport.java:94) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.build(XmiModelSupport.java:71) at org.eclipse.incquery.tooling.core.generator.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:137) at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60) at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:161) at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:188) at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:85) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) Balázs, don't debug it for now. After a short forum thread with Ed Merks, I found out I got the uri calculation algorithm wrong. Working on an alternative. Another implementation is committed, and it seems to work on both the modembed and the descent examples (we have validated it with Ábel). Balázs, can you please try again? I have also asked in the EMF Forum whether our new solution is as supported by EMF, and will not close the issue before I got an answer. The URI resolution issue should be fixed for now; Ed Merks confirmed that parent packages are to be handled the way they are in http://www.eclipse.org/forums/index.php/m/1008478/#msg_1008478. Alltogether, I am now optimistically marking this issue as fixed - but feel free to re-open if there remain some issues. Unfortunately it still doesn't work for me, I'm not sure why. It cannot generate queries for Autosar 4 models, the builder still fails with the following exception: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Unknown Source) at org.eclipse.incquery.tooling.core.generator.util.EMFPatternURIHandler.deresolve(EMFPatternURIHandler.java:63) 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:2294) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveHRefSingle(XMLSaveImpl.java:2378) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1561) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedSingle(XMLSaveImpl.java:2397) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1541) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2411) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1547) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1175) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2411) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1547) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1218) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2710) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:677) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:585) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:251) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:331) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1417) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:986) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelBuilder.build(XmiModelBuilder.java:195) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.internalBuild(XmiModelSupport.java:94) at org.eclipse.incquery.tooling.core.generator.builder.xmi.XmiModelSupport.build(XmiModelSupport.java:71) at org.eclipse.incquery.tooling.core.generator.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:137) at org.eclipse.xtext.builder.impl.RegistryBuilderParticipant.build(RegistryBuilderParticipant.java:60) at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:161) at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:188) at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:85) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) 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) For Autosar 3 models, the queries are generated, but cannot be executed. Running them from the query explorer causes the following exception: org.eclipse.incquery.runtime.exception.IncQueryException: The following error occurred during the preparation of an EMF-IncQuery pattern matcher: Error during constructing Rete pattern matcher; please review Error Log and consult developers at org.eclipse.incquery.runtime.api.impl.BaseGeneratedMatcher.accessMatcher(BaseGeneratedMatcher.java:44) at org.eclipse.incquery.runtime.api.impl.BaseGeneratedMatcher.<init>(BaseGeneratedMatcher.java:35) at com.thyssenkrupp.presta.ar.browser.ar300.consistency.invalidconnector.InvalidConnectorMatcher.<init>(InvalidConnectorMatcher.java:123) at com.thyssenkrupp.presta.ar.browser.ar300.consistency.invalidconnector.InvalidConnectorMatcherFactory.instantiate(InvalidConnectorMatcherFactory.java:34) at com.thyssenkrupp.presta.ar.browser.ar300.consistency.invalidconnector.InvalidConnectorMatcherFactory.instantiate(InvalidConnectorMatcherFactory.java:1) at org.eclipse.incquery.runtime.api.impl.BaseMatcherFactory.getMatcher(BaseMatcherFactory.java:42) at org.eclipse.incquery.tooling.ui.queryexplorer.content.matcher.ObservablePatternMatcherRoot.addMatchersForPatterns(ObservablePatternMatcherRoot.java:202) at org.eclipse.incquery.tooling.ui.queryexplorer.content.matcher.ObservablePatternMatcherRoot.registerPattern(ObservablePatternMatcherRoot.java:175) at org.eclipse.incquery.tooling.ui.queryexplorer.util.DatabindingUtil.createPatternMatcherRoot(DatabindingUtil.java:441) at org.eclipse.incquery.tooling.ui.queryexplorer.content.matcher.MatcherTreeViewerRoot.addPatternMatcherRoot(MatcherTreeViewerRoot.java:40) at org.eclipse.incquery.tooling.ui.queryexplorer.adapters.EMFModelConnector.loadModel(EMFModelConnector.java:67) at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.LoadResourceSetHandler.execute(LoadResourceSetHandler.java:35) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:829) at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:815) at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:805) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) Caused by: org.eclipse.incquery.runtime.rete.construction.RetePatternBuildException: Error during constructing Rete pattern matcher; please review Error Log and consult developers at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:59) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:1) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.construct(ReteBoundary.java:523) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.accessProduction(ReteBoundary.java:455) at org.eclipse.incquery.runtime.rete.construction.ReteContainerBuildable.patternCallStub(ReteContainerBuildable.java:125) at org.eclipse.incquery.runtime.rete.construction.psystem.basicdeferred.PatternCallBasedDeferred.getSideStub(PatternCallBasedDeferred.java:115) at org.eclipse.incquery.runtime.rete.construction.psystem.basicdeferred.NegativePatternCall.doCheckOn(NegativePatternCall.java:55) at org.eclipse.incquery.runtime.rete.construction.psystem.DeferredPConstraint.checkOn(DeferredPConstraint.java:38) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.admitStub(QuasiTreeLayout.java:141) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.admitStub(QuasiTreeLayout.java:141) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.admitStub(QuasiTreeLayout.java:141) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.run(QuasiTreeLayout.java:92) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout.layout(QuasiTreeLayout.java:49) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuildScaffold.construct(EPMBuildScaffold.java:58) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:57) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:1) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.construct(ReteBoundary.java:523) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.accessProduction(ReteBoundary.java:455) at org.eclipse.incquery.runtime.rete.matcher.ReteEngine$1.call(ReteEngine.java:179) at org.eclipse.incquery.runtime.rete.matcher.ReteEngine$1.call(ReteEngine.java:1) at org.eclipse.incquery.runtime.base.core.NavigationHelperImpl.coalesceTraversals(NavigationHelperImpl.java:677) at org.eclipse.incquery.runtime.internal.EMFPatternMatcherRuntimeContext.coalesceTraversals(EMFPatternMatcherRuntimeContext.java:193) at org.eclipse.incquery.runtime.rete.matcher.ReteEngine.accessMatcher(ReteEngine.java:175) at org.eclipse.incquery.runtime.api.impl.BaseGeneratedMatcher.accessMatcher(BaseGeneratedMatcher.java:42) ... 45 more Caused by: java.lang.NullPointerException at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.getUniqueIdentifier(NavigationHelperContentAdapter.java:99) at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.getInstanceSet(NavigationHelperContentAdapter.java:405) at org.eclipse.incquery.runtime.base.core.NavigationHelperImpl.getAllInstances(NavigationHelperImpl.java:339) at org.eclipse.incquery.runtime.internal.EMFPatternMatcherRuntimeContext.enumerateAllUnaryInstances(EMFPatternMatcherRuntimeContext.java:387) at org.eclipse.incquery.runtime.rete.boundary.EntityFeeder.feed(EntityFeeder.java:42) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.accessUnaryRoot(ReteBoundary.java:200) at org.eclipse.incquery.runtime.rete.construction.ReteContainerBuildable.unaryTypeStub(ReteContainerBuildable.java:161) at org.eclipse.incquery.runtime.rete.construction.psystem.basicenumerables.TypeUnary.doCreateStub(TypeUnary.java:38) at org.eclipse.incquery.runtime.rete.construction.psystem.EnumerablePConstraint.getStub(EnumerablePConstraint.java:39) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.run(QuasiTreeLayout.java:91) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout.layout(QuasiTreeLayout.java:49) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuildScaffold.construct(EPMBuildScaffold.java:58) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:57) ... 68 more I suspect that these problems are caused by some strangeness in our ecore files. We've generated them from UML models thus they contain some unconventional way of describing some of the elements. I will try to debug to the root cause of these exceptions. The builder fails if there is no "/" in the fragment of the EClass's URI. This can happen if the ecore file has ID set for the elements, like this:
<eClassifiers xsi:type="ecore:EClass" xmi:id="_mmtG__1917564164" name="EcucContainerValue"
eSuperTypes="#_mmtG_270654108 #//presta/AR402/AutoSARArchitect/IVariationPointContainer">...
(some elements doesn't have id, as the one referenced by 'eSuperTypes'.)
in this case, the URI looks like the following:
platform:/resource/com.thyssenkrupp.presta.ar.model.ver402/model/AUTOSAR_4-0-2.ecore#_mmtG__1917564164
It seems that in this case the runtime URI could only be built by querying the ecore model and not just by transforming the URI.
As it is unclear at the moment how to reproduce this issue in our environment, I'm postponing this issue to the next milestone (we'll continue to work on this, but we're pushing out M1 now). These enormous exception traces are completely unreadable and there is only one significant line: Caused by: java.lang.NullPointerException at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.getUniqueIdentifier(NavigationHelperContentAdapter.java:99) Obviously, the NPE conveys no information on what happened: 1. the passed EClassifier is an unresolvable proxy (since the URI was not generated properly) 2. EClassifier.getPackage returns null on the passed classifier 3. EPackage.getNsUri throws NPE So I added a precondition to the method that will throw IllegalArgumentException when the passed classifier is a proxy and print out the unresolved URI as well. Balázs, can you please check a few things: 1. Will the URI use the id in runtime as well, or would we need to transfrom it? platform:/resource/com.thyssenkrupp.presta.ar.model.ver402/model/AUTOSAR_4-0-2.ecore#_mmtG__1917564164 is turned to which of the following? a) someUri#//packages/_mmtG__1917564164 b) someUri#//packages/EcucContainerValue 2. What URIs are put into the package maps in EMFPatternURIHandler constructor? Both the value of EcoreUtil.getURI(package) and calculateModifiedUri(package) would be nice. This should help in deciding what to put in the different partial fragments when the index is -1 (no / in fragment). Thanks in advance! (In reply to comment #15) 1: ID will not be available through the reflective ecore model, therefore it shouldn't be used. Generally, the EClass URI should be in the following form: "nsURI#//EClassName" EMF can load a runtime ecore package by its namespace URI. Then this ecore package contains the referenced class directly. 2: Unfortunately i won't have time today to look up this info for you. I will try to do it this weekend. B; I have submitted an alternative implementation for handling ID-based URIs. Balázs, please see if it helps in your case. (In reply to comment #17) It's almost working. it produces the following uri: http:///M2/AR30/SWComponentTemplate/Composition.ecore#/CompositionType instead of this: http:///M2/AR30/SWComponentTemplate/Composition.ecore#//CompositionType the platform cannot resolve the first URI causing an exception when trying to execute the queries. (In reply to comment #18) It seems that this problem is solved by the patch I've posted for #398720. There are still some URIs which are generated incorrectly (I'm not yet sure why..) Caused by: java.lang.IllegalArgumentException: Classifier org.eclipse.emf.ecore.impl.EClassImpl@9bdf6f9 (eProxyURI: http:///M2/AR30/SWComponentTemplate/Composition.ecore#//M2.AR30.SWComponentTemplate.Composition._instanceRef/AssemblyConnectorPrototype_provider) is an unresolved proxy at com.google.common.base.Preconditions.checkArgument(Preconditions.java:88) at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.getUniqueIdentifier(NavigationHelperContentAdapter.java:100) at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.getInstanceSet(NavigationHelperContentAdapter.java:408) at org.eclipse.incquery.runtime.base.core.NavigationHelperImpl.getAllInstances(NavigationHelperImpl.java:339) at org.eclipse.incquery.runtime.internal.EMFPatternMatcherRuntimeContext.enumerateAllUnaryInstances(EMFPatternMatcherRuntimeContext.java:387) at org.eclipse.incquery.runtime.rete.boundary.EntityFeeder.feed(EntityFeeder.java:42) at org.eclipse.incquery.runtime.rete.boundary.ReteBoundary.accessUnaryRoot(ReteBoundary.java:200) at org.eclipse.incquery.runtime.rete.construction.ReteContainerBuildable.unaryTypeStub(ReteContainerBuildable.java:161) at org.eclipse.incquery.runtime.rete.construction.psystem.basicenumerables.TypeUnary.doCreateStub(TypeUnary.java:38) at org.eclipse.incquery.runtime.rete.construction.psystem.EnumerablePConstraint.getStub(EnumerablePConstraint.java:39) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout$Scaffold.run(QuasiTreeLayout.java:86) at org.eclipse.incquery.runtime.rete.construction.quasitree.QuasiTreeLayout.layout(QuasiTreeLayout.java:44) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuildScaffold.construct(EPMBuildScaffold.java:58) at org.eclipse.incquery.runtime.internal.matcherbuilder.EPMBuilder.construct(EPMBuilder.java:57) ... 67 more Can you elaborate what is the expected output and what was the input. Sadly, it is really hard to solve this issue without knowing what have gone wrong... Or can you provide some small example that reproduces this issue? (In reply to comment #21) The problem originates in calculateModifiedUri(EPackage). It returns a fragmented uri for packages that have a non-empty parent package. Why is that? I think every package should be identified by its nsURI. Nope, the parent package stuff is needed. See the previously linked EMF forum thread for details: http://www.eclipse.org/forums/index.php/m/1008478/#msg_1008478 Basically, not nsUris, but parent nsUris are used to identify the package in case of nested packages. I don't know, why is EMF implemented that way, but that works for both the Descent model introduced by Ábel's student and the ModEMBED model you presented. The question here is why is it different in your other metamodel. Can you use a method like the following to get the expected type url from the corresponding instance model class? private void printData(EObject content) { System.out.println(String.format("%s", EcoreUtil.getURI(content.eClass()))); } (In reply to comment #23) I was wrong, your interpretation of the EClass URI is correct. I queried the runtime URIs of all EClasses from the registered EPackages, and compared them to the generated URIs. I've found out that the calculateModifiedUri should put the name of the EPackage in the fragment sections instead of the nsPrefix: while (nonEmptySuperPackage(p) != null) { fragments.add(p.getName()); p = nonEmptySuperPackage(p); uriString = p.getNsURI(); } This way, most of the queries started working. Now I get some EClass URIs contain another package uri, not the one which contains that particular EClass, like this: the globalEiqModel contains this: http:///AUTOSARRoot/M2/AUTOSARTemplates/ECUCParameterDefTemplate.ecore#//EcucContainerValue instead of this: http:///AUTOSARRoot/M2/AUTOSARTemplates/ECUCDescriptionTemplate.ecore#//EcucContainerValue currently I'm trying to debug this.. Created attachment 227324 [details]
Fixed URI calculation when EClass is identified by xmi:id
After applying these changes, the builder generates the URIs correctly, and all of our queries works.
1] Did you agree to contribute the code to the Incquery project, a) to be licensed as open source under the EPL agreement?; Yes. 2] Did you [yourself] write the code you contributed to the Incquery project? Yes. 3] Does anyone else have rights to the code you contributed? [For example, did you have an agreement with an employer giving the employer rights to all code you wrote during that time?] No, I've written the code in my free time. It seems, we have managed to fix this issue. Let's hope, everything's fine for now. Closing. |