Skip to main content



      Home
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 Go to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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:
  


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

Powered by FUDForum. Page generated in 0.07743 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top