Eclipse Community Forums: TMF (Xtext) » Reference model elements from target platform

Home » Modeling » TMF (Xtext) » Reference model elements from target platform(How is it possible to provide parts of the model reflected in my DSL in bundles in the target platform)

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

Reference model elements from target platform [message #1844417]

Mon, 13 September 2021 14:01

Markus Duft

Messages: 35
Registered: March 2015

Member

We have multiple quite extensively used DSLs built on Xtext. Since our workspace is slowly disintegrating since its so massive, we would like to shift projects which are not that commonly directly edited to the target platform for our product. This also includes a lot of bundles with DSL sources. Once we shift those bundles to the target platform and clean build the workspace, the elements in the DSL files inside the bundles are no longer available, also if we include the according sources in the bundles.

This all makes sense, and I fully understand WHY this is the case (no builder running on bundles in the target platform, thus elements never "compiled" and added to the global index, thus not available). My question now is what is the best approach to get those elements loaded from the target platform, so they are available when required, e.g. as base classes for other DSL elements, or programmatically/globally when searched for...

Anybody any experiences? I can't seem to find any information on the subject.

Report message to a moderator

Re: Reference model elements from target platform [message #1844418 is a reply to message #1844417]

Mon, 13 September 2021 14:06

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

Hi,

i cannot follow you. if you reference jars that contain model files in your manifest then the files should be indexed and be available.
did you double check the files are really in jar (the real one, not the source)?

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

[Updated on: Mon, 13 September 2021 14:07]

Report message to a moderator

Re: Reference model elements from target platform [message #1844420 is a reply to message #1844418]

Mon, 13 September 2021 14:15

Markus Duft

Messages: 35
Registered: March 2015

Member

Hi,

(thanks for the lightning fast reply :)). I think there is a misunderstanding, sorry was not specific enough :D We have DSLs which do *not* produce generated files. Instead they are used as in-memory model which we need to load in various places in the IDE. This model is composed of hundreds of DSL-source-files. We now wan't to edit one of those files, and have other source files in the target platform. For another similar-but-not-same case (to be able to use the model in an external application) we use 'org.eclipse.emf.ecore.resource.impl.BinaryResourceImpl' to save and load them in another application - however this is not used in conjunction with editors & co (we want all the nice editing to work) but is some seperate external code.

Report message to a moderator

Re: Reference model elements from target platform [message #1844421 is a reply to message #1844420]

Mon, 13 September 2021 14:33

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

and what is the "slow" part you want to optimize?
or if slowness is not the problem and having no project is: why not creating a hidden project.

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

[Updated on: Mon, 13 September 2021 14:41]

Report message to a moderator

Re: Reference model elements from target platform [message #1844448 is a reply to message #1844421]

Tue, 14 September 2021 11:05

Markus Duft

Messages: 35
Registered: March 2015

Member

The "slow" part is having 700+ projects with ~7 Million lines of code in a single workspace. We need to approach that a little different. Long story short, we cannot keep all projects in the workspace. The models we build using our DSLs are distributed among various layers, modules, etc. We would like to continue using the DSLs without the need to have all dependencies as source projects in the workspace, and rather have them in the target platform as binaries which is *waaaay* cheaper.

We 'just' need to convince Xtext (editor, builder) to be able to 'see' the parts of the model which is now in the target platform. I'm looking for a way to do it. If we can use the actual DSL source files from the target platform somehow, that would be ideal. If we need some kind of other representation, I wonder what it could look like, and also how we could populate the global Index somehow from the target components a "the right point in time" - so before a builder or editor needs it...

Report message to a moderator

Re: Reference model elements from target platform [message #1844450 is a reply to message #1844448]

Tue, 14 September 2021 11:38

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

if parsing is still fast enhough (== resolve 6 validate is the problem) then the default parse from jar could still be fast enhough

i guess then you would gave to do some custom stuff that side loads information to the Xtext index and make this stuff visible in scoping
(nothing ootb, no code available to my knowledge to c&p from)

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

[Updated on: Tue, 14 September 2021 11:38]

Report message to a moderator

Re: Reference model elements from target platform [message #1844453 is a reply to message #1844450]

Tue, 14 September 2021 12:25

Markus Duft

Messages: 35
Registered: March 2015

Member

Yeah, I think that parsing the DSL files should be OK. Just need to know how to feed them to Xtext xD Any hints? Is Scoping the only required thing to be done? How can we load and put things in the index? manually in the "correct" order using a custom ResourceSet?

[Updated on: Tue, 14 September 2021 12:26]

Report message to a moderator

Re: Reference model elements from target platform [message #1844455 is a reply to message #1844453]

Tue, 14 September 2021 13:01

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Clearly 700 projects will be 'slow' by some metric but I don't see that it need be catastrophically slow.

For my OCL and QVTd work, I observed that the Xtext builder/indexer just loved to burn CPU time and associated Bugzillas remain open in regard to rebuild cycles.

I mitigated the problem by excluding the Xtext nature and build dependencies from all DSL projects. Instead one OCL and one QVTd build project host all the MWE2 scripts and launches, so that only the build projects get excessively built. This has the additional benefit of eliminating compile-time only dependencies from the DSL projects.

This is possible for OCL and QVTd since they have their own IScope implementation that makes zero use of Xtext's index-the-world 'convenience'. IMHO the necessary references should always be the consequence of some import and so a respectable parser has a closed deterministic search space in which valid targets are guaranteed to be found by qualified path resolution. It should not be necessary to have an Xtext nature in every project that requires all possible DSL files to be indexed unnecessarily. It is only for an interactive Find References to e.g. a Java class target that a lazy system scan may be needed necessitating a please wait pop-up. NB An index-the-world has the interesting ability to find an alias for self that resulted in the interesting phenomenon that after explicitly starting an execution of an MWE2 script, it would search for itself, find another version from a failed clone experiment and so lead to a meg-debugging excitement as the wrong script executed. Sadly the undesirable Xtext nature has infected org.eclipse.emf.ecore to support Xcore. Fortunately it has not been adopted by UML2 for which indexing times could be really unpleasant.

Regards

Ed Willink

Report message to a moderator