Eclipse Community Forums: TMF (Xtext) » Building the index in Eclipse for non-Java projects?

Help

Home

Home » Modeling » TMF (Xtext) » Building the index in Eclipse for non-Java projects?

Show: Today's Messages :: Show Polls :: Message Navigator

Building the index in Eclipse for non-Java projects? [message #1818808]

Sun, 29 December 2019 18:03

Marc-André Laperle

Messages: 256
Registered: July 2009

Senior Member

I am experimenting with a Json-based language. It does not interact with the JVM and classpaths in any way. Some elements in this language cross reference to other files so I am trying to setup cross referencing correctly. From what I understand, it's the responsibility of the XtextBuilder (an Eclipse incremental builder) to go through all the resources and build the index (IResourceDescriptions?).

When visiting the resources to be built, XtextBuilder calls ToBeBuiltComputer.isHandled which ends up calling JdtToBeBuiltComputer.isPossiblyHandled which checks: resource instanceof IJarEntryResource. Of course, since my files have nothing to do with Java, it returns false and nothing gets "built".

I tried binding another IToBeBuiltComputerContribution to my own JDT-less implementation but it always ends up using JdtToBeBuiltComputer anyway. I don't know if I'm doing something wrong with google.inject or if I am completely on the wrong path.

Here is the code for my runtime module:

public class JsonDslRuntimeModule extends AbstractJsonDslRuntimeModule {
@Override
public Class<? extends Manager> bindIContainer$Manager() {
return SimpleResourceDescriptionsBasedContainerManager.class;
}

@Override
public void configure(Binder binder) {
super.configure(binder);
binder.bind(IToBeBuiltComputerContribution.class).to(MyToBeBuiltComputerContributionImplementation.class);
}
}

BTW, it's the second time I try to get this type of cross-referencing working, previously ~6 years ago and I was also stuck around the same area. Perhaps I keep doing the same mistake or have the same misunderstanding. So any help putting me on the right path would be greatly appreciated!

Report message to a moderator

Re: Building the index in Eclipse for non-Java projects? [message #1818809 is a reply to message #1818808]

Sun, 29 December 2019 20:28

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

bindings for IToBeBuiltComputerContribution are usually bound via a separate module class and registered via org.eclipse.xtext.ui.shared.sharedStateContributingModule extension point

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Building the index in Eclipse for non-Java projects? [message #1818811 is a reply to message #1818809]

Sun, 29 December 2019 21:08

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

Btw xtext supports references between dsl files in non Java projects ootb

I am not sure what you plan with your jar but you may have to have a look at storage2uri mappers too

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

[Updated on: Sun, 29 December 2019 21:10]

Report message to a moderator

Re: Building the index in Eclipse for non-Java projects? [message #1818862 is a reply to message #1818811]

Tue, 31 December 2019 05:08

Marc-André Laperle

Messages: 256
Registered: July 2009

Senior Member

Hi Christian, thanks a lot for your help! So the first mistake I made was that I misconfigured the "extensions" field in the Xtext project wizard, I had "jsondsl" as it was also the name of my prototype language and I probably thought I'd start with that and change it later. But I ended up testing with .json files. Then I was working backwards to fix this by trying to binding things manually. Then another mistake was that I misinterpreted ToBeBuiltComputer.isHandled:

boolean possiblyManaged = contribution.isPossiblyHandled(storage);
if ((possiblyManaged || storage instanceof IFile) && uriValidator.isPossiblyManaged(storage)) {

For non-Java projects it falls in the "storage instanceof IFile" branch and it's "uriValidator.isPossiblyManaged(storage)" that's actually the culprit. Then I noticed that the registry's extensionToFactoryMap only contains jsondsl as a key and not json. Since you seem to imply that what those cross-references should work ootb without this kind of modification, I grew suspicious. I noticed in the .mwe2 file that I could change fileExtensions to "json" instead of "jsondsl", then I did a "Generate Language Infrastructure" again. Surprisingly, that turned out to not regenerate everything and the UI plugin's plugin.xml still contains mentions of "jsondsl" as file extension, among others. In fact, then I tried to run, I got exceptions such as:
org.eclipse.xtext.builder.resourceloader.IResourceLoader$LoadOperationException: org.xml.sax.SAXParseExceptionpublicId: platform:/resource/testdsl/test.json; systemId: platform:/resource/testdsl/test.json; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog.
at org.eclipse.xtext.builder.resourceloader.SerialResourceLoader$1.next(SerialResourceLoader.java:50)

So, I ended up starting from scratch a new Xtext project and setting the "extensions" field correctly. Now it is working properly.
But I don't quite understand the proper workflow of Xtext with regards of code generation with mwe2, emf, xtend, etc. It doesn't make sense to me that I'd have to restart from scratch whenever I want to edit the language file extensions in mwe2, or perhaps I am not generating correctly... or perhaps it is expected to only generate once at the beginning and edit everything by hand after? Perhaps there is something in the documentation that I missed about that or you know of a good source of information that could clear this up for me? You have already helped me through my original problem so thanks a lot in any case!

Report message to a moderator

Re: Building the index in Eclipse for non-Java projects? [message #1818872 is a reply to message #1818862]

Tue, 31 December 2019 08:57

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

As the plugin.xml may contain manually written code
After rerunning the workflow Xtext will generate a
plugin.xml_gen which needs to be merged into plugin.xml by you

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator