I have three xtext project with same grammar. I want to access the runtime instance of 1st and 2nd project in 3rd runtime instance.
Please guide me.
This is my Scenario
Regards,
Misbah.
Related
I need to know the user name and other data of the logged-in user in a project organized using BPLs. That is, how and where do I need to declare the user object and its creation, and how to get access to that object when a package is loaded at runtime? I don't have enough experience working with packages.
In a regular app, for the programmer there is no difference between using runtime packages or all in a single exe
You can change the project to go with runtime packages or not, and your code won't change at all
That changes when you make a modular app that loads BPL modules on demand, chosing at runtime if a given module will be load, and doing it dynamically (ex. app made with a plugin-architecture in mind), then you need to design your own strategy to handle that
Myself, I work in that second way, and I do have some main modules wich give services to the "plugins", so when they are loaded, they do register themselves with the system: user control, navigation, whatever
There is nothing special to use objects in a package. You just add the unit name where the object is defined to the uses clause of the unit where the object is to be used.
You should really read the documentation on this topic. The you may ask more questions to clarify things you don't understand.
I have two Eclipse plugin Xtext(2.11) projects.(Called Project A and B) Project B grammar file is dependent on Project A grammar file. Project A's grammar file extension is a and Project B is b.
I am able to generate the language server for Project B. I want to generate the single language server for both projects.(Currently, in project B it includes project A.)
Depend on extension type it needs invoke respective Xtext grammar functionality.
In above scenario, I have below questions:
Does Xtext can handle this kind of scenario seamlessly? Do I need to generate the language server for Project A also and need to add in Project B? What is the best way to do this?
What kind of Xtext changes required?
What kind of changes required at client side also? like in Visual code/ Che?
Xtext LS can be used with multiple Xtext languages. It uses java service loading to look up language setups: https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/ResourceServiceProviderServiceLoader.xtend#L25. In ide project of your language you should be able to find META-INF/services/org.ecalipse.xtext.ISetup file that says java what implementations should be used for ISetup interface.
Having jars for ide projects on the classpath should be enough. No changes are required.
VS code and Che does not care about implementation details of Xtext LS, but both languages should be registered for them
I want to create custom project template based on F# project (fsproj). Requirements:
Custom project properties. So, property page extension required.
Custom file type support. Custom project item template should be created.
Custom build action for custom file type. Corresponded MsBuild task will be created.
As I know, some parts of C# project ecosystem are in SDK, so can be inherited (it looks useful for deep customization), but F# is not. So my question is what the best way for deep customization of F# project template?
I want to use the runtime configuration for running an xText parser. In an example xText project I get the standalone and the runtime configuration for using the parser.
Please can somebody indicate the steps needed to use the parser during runtime in another Eclipse plug-in project. I have no experience with the plugin.xml file and I know I need to create there some extension points.
The xText sample project contain also an ui project which uses the obtained parser during runtime. Still I was not able to understand what things I need from that configuration an what not.
Help is highly appreciated.
I understand how to implement a StructureMap registry, my question concerns the fact that every project that contains a StructureMap registry requires a static reference to the StructureMap assembly. Is there a best practice for how to structure the configuration for a large number of projects (30+) without forcing each project to take this dependency?
The alternative, I suppose, would be to create a bootstrapper assembly that could be referenced by the host process. The bootstrapper would perform all wire-up. In this scenario, the bootstrap assembly, instead, would have references to all of the projects. This has the upside of centralizing the reference to StructureMap so that all of the projects are unaware of StructureMap.
Using XML-based configuration is not an option for me.
Are there any other options for configuration that minimize the number of static references the projects in the solution must take? I'm guessing that there isn't, but thought I'd solicit some other opinions.
Technically, you only need a single project to reference the container framework, and that is the top-level application project. It references all the other projects and specifies the configuration of the components.
This puts the entire graph configuration out of the hands of each project, opting instead to define graphs only where they are used. This gives each application the complete freedom to configure components, rather than assuming the components will be used in the same way every time (as is implied by the registries which are inherent to each project).
An aside that may or may not be useful: in quantum physics, when we observe a particle, we collapse it from every possible state into a particular one. Frameworks are similar, in that they don't exist in a single state until they are observed, which here means "put to use in an application." This frames the application as the observer, which is the context in which the framework collapses into a single form.
Now, I generally wouldn't want the application be responsible for both being a running application and also configuring that runtime. For this reason, I tend to have a Composition project which references the others as well as the container framework. The actual application project can then reference the Composition project. This externalizes the registries from each project, including the application project, producing a cohesive assembly whose sole purpose is to define the composition of a particular application.