search

viatra / EMF-IncQuery

This repository is only kept for historic reasons. All development happens on eclipse.org
http://eclipse.org/viatra
13 stars 4 forks source link

Pattern does not show up in plug-in pattern registry #352

Closed okrosa closed 11 years ago

okrosa commented 11 years ago

Might be related to #302, but I will open a separate issue for sure.

I made some patterns with the @QueryExplorer tag, and exported them into the host eclipse. After restarting the runtime the patterns show up in the Query Explorer correctly. (During this the eiq files with the pattern definitions are opened in the runtime.) If I comment out the tagged patterns and restart the eclipse I got an error, and the patterns does not show up in the plug-in part of the registry.

!STACK 0
java.lang.IllegalArgumentException: No pattern specified for getFullyQualifiedName
    at org.eclipse.viatra2.patternlanguage.core.helper.CorePatternLanguageHelper.getFullyQualifiedName(CorePatternLanguageHelper.java:63)
    at org.eclipse.viatra2.emf.incquery.runtime.api.impl.BaseMatcherFactory.getPatternFullyQualifiedName(BaseMatcherFactory.java:58)
    at org.eclipse.viatra2.emf.incquery.runtime.extensibility.MatcherFactoryRegistry.initRegistry(MatcherFactoryRegistry.java:85)
    at org.eclipse.viatra2.emf.incquery.runtime.extensibility.MatcherFactoryRegistry.createMatcherFactories(MatcherFactoryRegistry.java:54)
    at org.eclipse.viatra2.emf.incquery.runtime.extensibility.MatcherFactoryRegistry.<clinit>(MatcherFactoryRegistry.java:40)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.util.DatabindingUtil.collectGeneratedMatcherFactories(DatabindingUtil.java:115)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.util.DatabindingUtil.getGeneratedMatcherFactories(DatabindingUtil.java:142)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.util.DatabindingUtil.collectGeneratedPatterns(DatabindingUtil.java:156)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.util.DatabindingUtil.getGeneratedPatterns(DatabindingUtil.java:149)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.QueryExplorer.initPatternsViewerWithGeneratedPatterns(QueryExplorer.java:322)
    at org.eclipse.viatra2.emf.incquery.queryexplorer.QueryExplorer.createPartControl(QueryExplorer.java:270)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:129)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityView.createPartControl(CompatibilityView.java:155)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:300)
    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.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
    at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:857)
    at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:837)
    at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:111)
    at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:318)
    at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:240)
    at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:161)
    at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
    at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
    at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
    at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:141)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:889)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:623)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$6.run(PartRenderingEngine.java:511)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:496)
    at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:74)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:889)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:623)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:725)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:696)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:690)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
szabta89 commented 11 years ago

The QueryExplorer tag is necessary for generated patterns to be included into the Pattern Registry.

okrosa commented 11 years ago

The tag is there, that is why the patterns show up in the first place in the plug-in pattern registry. The fact, that I comment out the whole pattern after in the eiq file should not affect at all the generated code in the host eclipse (which is not changed after the first export).

istvanrath commented 11 years ago

Action plan to resolve this issue:

  1. BaseGeneratedMatcherFactory should NEVER look in workspace resources for global XMIs (see XmiModelUtil)
  2. implement a validator that throws a big warning if
    • your code contains a pattern FQN that is already present in the plug-in pattern registry
    • AND the editor is opened on a workspace resource
ujhelyiz commented 11 years ago

Action plan item 1 relates to #281 - more specifically, a solution for this essentially blocks all use cases for dependencies.

A minor remark about action plan 2: it is surprisingly hard to write a validation that relies that much on Eclipse context. That kind of information is not available there - in the Xtext those validators are not really supported.

istvanrath commented 11 years ago

Please elaborate more on your first remark ("blocks all use cases for dependencies").

ujhelyiz commented 11 years ago

Sorry for not being clear (midnight effect :) ). I wanted to say, that the removing the workspace dependency (workspace lookup) is required to even consider a non-Eclipse integration of EMF-IncQuery based on the generated pattern matcher code.

However, as the fix of #172 added new dependencies of incquery.runtime, this is not the only place needs to be fixed to support Java applications (without OSGi), but it is still an important step.

okrosa commented 11 years ago

First part (bugfix):

Second part (extra validator): based on the comment of @ujhelyiz I suggest we should not deal with it now, as this whole issue is quite marginal.

Based on this if my last commit is decided to be sufficient I'll be propose to set this issue to resolved as well.

okrosa commented 11 years ago

Cherry pick completed.

istvanrath commented 11 years ago

Everything seems to be working fine so I'm closing this.