Eclipse Community Forums: TMF (Xtext) » importURI with Xtext 2.14 and the new generator

Home » Modeling » TMF (Xtext) » importURI with Xtext 2.14 and the new generator

importURI with Xtext 2.14 and the new generator [message #1790023]

Sun, 03 June 2018 06:59

Eclipse User

Hello,

After migrating to Xtext 2.14 and the new generator, importURI is not working as expected anymore.

I have 2 Xtext languages a and b. Runtime environment is Eclipse. Within the same workspace file fileA.a in projectA imports a file fileB.b from projectB like

  import "project://projectB/fileB.b";

Both projects are configured with "Xtext Nature", project A references project B.

I get the error "- Imported resource could not be found.". When I move fileB.b to projectA (and change the import accordingly), the import works.

In the grammar A.xtext I have:

Import:
  'import' importURI=STRING ';';

In the workflow GenerateA.mwe I have these fragments (according to what I found here in the forum, the documentation, and elsewhere):

			fragment = org.eclipse.xtext.generator.adapter.FragmentAdapter {
            	fragment = org.eclipse.xtext.generator.scoping.ImportURIScopingFragment {}
            	fragment = org.eclipse.xtext.generator.exporting.SimpleNamesFragment {}
 			}
//			fragment = exporting.SimpleNamesFragment2 {}
		    fragment = grammarAccess.GrammarAccessFragment2 {}
		    fragment = ecore.EMFGeneratorFragment2 {}
		    fragment = serializer.SerializerFragment2 {
		    	generateStub = false
		    }
		    fragment = resourceFactory.ResourceFactoryFragment2 {}
		    fragment = parser.antlr.XtextAntlrGeneratorFragment2 {}
		    fragment = validation.ValidatorFragment2 {
		    	composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"
//	   		    composedCheck = "org.bricks.gdl.validation.GdlValidator"
		    }
//		    fragment = scoping.ImportNamespacesScopingFragment2 {}
//	        fragment = exporting.QualifiedNamesFragment2 {}
		    fragment = builder.BuilderIntegrationFragment2 {}
		    fragment = generator.GeneratorFragment2 {}
		    fragment = formatting.Formatter2Fragment2 {}
		    fragment = ui.labeling.LabelProviderFragment2 {}
		    fragment = ui.outline.QuickOutlineFragment2 {}
		    fragment = ui.outline.OutlineTreeProviderFragment2 {}
		    fragment = ui.quickfix.QuickfixProviderFragment2 {}
		    fragment = ui.contentAssist.ContentAssistFragment2 {}
		    fragment = junit.JUnitFragment {
				junitVersion = "5"	    	
		    }
		    fragment = ui.refactoring.RefactorElementNameFragment2 {}
//		    fragment = types.TypesGeneratorFragment2 {}
//		    fragment = xbase.XtypeGeneratorFragment2 {}
//		    fragment = xbase.XbaseGeneratorFragment2 {}
		    fragment = ui.templates.CodetemplatesGeneratorFragment2 {}
		    fragment = ui.compare.CompareFragment2 {}
		    fragment = idea.parser.antlr.XtextAntlrIDEAGeneratorFragment {}
		    fragment = idea.IdeaPluginGenerator {}
		    fragment = web.WebIntegrationFragment {
		        framework = "Ace"
		    }
		    fragment = ui.projectWizard.TemplateProjectWizardFragment {}
		    fragment = ui.fileWizard.TemplateFileWizardFragment {}

There is no changes to scoping or linking implemented (as this was not needed before)

What am I missing to get the cross-project import work?

Re: importURI with Xtext 2.14 and the new generator [message #1790024 is a reply to message #1790023]

Sun, 03 June 2018 10:08

Eclipse User

Simply have a look at the bindings the old fragments did and do them annually and you are fine

Re: importURI with Xtext 2.14 and the new generator [message #1790028 is a reply to message #1790024]

Sun, 03 June 2018 11:57

Eclipse User

Hello Christian, many thanks for answering.

Hm, I had two bindings in the runtime module

class ARuntimeModule extends AbstractARuntimeModule {
	
	def Class<? extends LinkingDiagnosticMessageProvider> bindLinkingDiagnosticMessageProvider() {
		return ALinkingDiagnosticMessageProvider
	}

	def Class<? extends AbstractAScopeProvider> bindAbstractAScopeProvider() {
		return AScopeProvider
	}
}

The message provider is still there. The scope provider was actually empty in the old setup (class defined but no functions at all). Now, with the new fragment settings above, there is not even the AbstractAScopeProvider generated, so I omitted the binding (?). There were no other bindings. What's needed now?

From debugging, I see importUriValidator.checkImportUriIsValid fails with checking for

 (Resource.Internal)getField(RESOURCE)

(lower 16 bits of eFlags is 4 (ADAPTER)).

Re: importURI with Xtext 2.14 and the new generator [message #1790030 is a reply to message #1790028]

Sun, 03 June 2018 12:46

Eclipse User

i cannot follow you.

- take the workflow as the wizard created it
- have a look at the bindings the old fragments ImportURIScopingFragment and SimpleNamesFragment registed and add these to your ui and runtime module.
(the bindigs where generated to the abstractmodules)
- please note that

import "project://projectB/fileB.b";

was never valid in xtext

Re: importURI with Xtext 2.14 and the new generator [message #1790500 is a reply to message #1790030]

Mon, 11 June 2018 17:26

Eclipse User

Yes, it is enough to use the fragment adapter. The URLs were causing the confusion. The target environment for the language is a 3rd party Eclipse based product, where "project://projectB/fileB.b" is indeed a valid URL (we are using this for years now). For development I use a standard Eclipse, where this does not work. Many thanks anyway.

Previous Topic:	Working with INT optional features - default value feature
Next Topic:	Problem parsing expression

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jun 24 10:27:03 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter