In the Inferring a JVM Model section of the Xtext documentation (http://www.eclipse.org/Xtext/documentation.html#_17) it starts by saying:
"In many cases, you will want your DSLs concepts to be usable as Java elements. E.g. an Entity will become a Java class and should be usable as such".
In the example above, how can I use the generated Entity class outside of xbase, i.e. in real Java code in a different project to the xtext one?
What I am essentially asking is if the Java classes created my by the model Inferrer can actually be used as real java classes, which can have their methods called and fields accessed from java code, in an altogether different project, and if so how this can be done?
My going through the documentation has lead me to fear that the generated "Java classes" are only Xbase types, only referenceabe in an xtext context, and are not therefore real java classes...
The Xbase compiler can compile all Xbase expressions to plain Java code usable everywhere where Java codes are available.
If you add your own elements to the language, you have to extend the generator to also support these elements - for this reason you define your own JVMModelInferrer.
The basic Xtext compiler then executes the JVMModelInferrer, calculates the JVM model that might (or might not) contain Xbase expressions as well; then this JVM model can be generated into a Java-compilable (thus Java-reusable) code.
If you want to test this functionality, simply generate the Xtext Domain Model example (available from the New... wizards in Xtext/Examples category), and evaluate the results: when you edit your domain model, Xtext automatically generates the usable Java code (if the required dependencies are set).
Related
In my Java 8 Play 2.6 application I have this particular line in a MessageConsumer class that reads a "Rule" record in the DB and sends the JSON message (node) to a specific processor based on the type configured on the rule column. ProcessType is an enum of Sub Classes that all extend from a base (Super class) process.
Play.current().injector().instanceOf(ProcessType.getClass(matchingRule.getProcessType())).processMessage(node, matchingRule);
I'm having trouble figuring out how to refactor this and don't want to add the allowGlobalApplication = true config parameter if I can avoid it.
The most straightforward approach is to inject the Injector into the component that contains this call (the MessageConsumer). This can be done the same way as any other Play component.
You can also inject the Application instance, which would return the same thing as Play.current(). This could be useful if you need more information from the Application object, but if not, injecting the Injector directly would be preferable, as it would create less coupling between the MessageConsumer and other components.
This assumes that the MessageConsumer is created by DI itself. If not, please add more details to the question, including the context code.
How can I access the typed abstract syntaxe tree for all source files in a f# project in order as descibed in "analysing a whole project". So, what I need is the specific Microsoft.FSharp.Compiler.Tast of all files in a project.
Accessing the untyped syntax tree is quite simple, as described in walking an untyped ast. So, I expect there to be a corresponding interface to the tast.
The purpose is to transpile code from F# to another typed language, in this case scala, which need type annotations. A whole project should be translated at once.
The first URL you link shows how to get an FSharpAssemblySignature, but doesn't explain much of what to do with such a value. That type, and the immediate types it contains, FSharpEntity & FSharpMemberOrFunctionOrValue, are defined in Symbols.fs. The typed AST itself is defined in tast.fs. I don't know of any docs explaining the various types, except the comments in these two files.
certainly I have not read something fundamental, and it seems very strange, but I wonder.
Suppose you use
#SharedPref
public interface SharedPreferencesInterface {
#DefaultBoolean(true)
boolean showDeviceName();
I have the IDE (idea) configured with Gradle, and I generated the SharedPreferencesInterface_ class that I can use in another class as
#Pref
SharedPreferencesInterface_ prefs;
But suppose someone now download the project, how can the use? Because the class where used SharedPreferencesInterface_ not compile because the class does not exist, and the class does not exist because compilation errors ...
How it's made? Surely there is a way ... configured to compile certain classes first?
Help is appreciated.
A greeting.
But suppose someone now download the project, how can the use? Because
the class where used SharedPreferencesInterface_ not compile because
the class does not exist, and the class does not exist because
compilation errors ...
This is the same situation when you compile a project in a full build (when no classes are generated yet). Actually Gradle always does a full build currently in Android projects. No configuration is needed at all in addition to the standard AndroidAnnotaions config.
Actually this works because the compiler does not fully compiles your class before passing it to annotations processing. It is clear it should not to, because the class may reference generated classes, which are only available after the processing. So first the compiler creates a model of the classes, only parses the structure of the them (fields, methods, return types, parameter types, etc), but not the implementations. Also it allows missing types even on fields. If it finds a missing type, it assigns to TypeKind.ERROR, but the name of the type is still available for the annotation processor. After the processor is done, it generates the missing class, so the kind of the class is no longer TypeKind.ERROR, and the compilation can succeed.
Currently I'm modifying a project that uses xText to parse a custom DSL. I want to add functionality to the generated classes but unfortunately I failed implementing the generation gap pattern. I used this article as a basis:
http://heikobehrens.net/2009/04/23/generation-gap-pattern/
My problem is that we're using a lot of Fragments to customize the org.eclipse.xtext.generator.Generator. It seems I cannot reuse those fragments for org.eclipse.xpand2.Generator.
So in conclusion:
how can I implement the generation gap pattern for the xtext generator
OR how can I use Fragments with the xpand2-Generator
OR is there a third solution that allows me to use fragments and implement the generation gap pattern?
After researching the matter, I'm thoroughly confused.
The generation gap pattern described in the article will work with almost any general purpose code generation framework. Xtext is no exception to this.
Besides that, Xtext offers another nifty solution to fill the generation gap. This is Xbase. But Xbase forces you to tightly integrate with java, so this is not always an alternative.
Consider following steps adding generation gap pattern to the existing Xtext project:
Locate generated file with the gap (with the code fragment you want to write by hand). Let it be e.g. MyClass.
Alter generator so that
the generated file get renamed to the AbstractMyClass.
the abstract keyword get added to the AbstractMyClass class definition.
the gap get moved to a single method.
an abstract method get generated for the gap.
the abstract method get called from the generated code.
Add 'MyClass extends AbstractMyClass' by hand and implement the abstract gap-method
If you have concrete problems with some Xtend2 code, post questions here or in Xtend forum.
A rule in xText called "Component" will typically generate a class "Component" in the src-gen folder.
I would like to add additional methods to these classes without them being overridden every time I make minor changes to the DSL. What's the proper way to inject my own code into these classes and is there a way to make all classes extend my own root class instead of the default EObject?
Thanks in advance.
You basically have two choices:
You can use a IXtext2EcorePostProcessor to modify the EMF-model which Xtext inferred from your grammar. The actual code generation is done by EMF, so you have to fiddle your code through that bottleneck. The details are described in a blog of Christian Dietrich. This approach is only suitable for small modifications.
You can use the "generation gap pattern" (a.k. "implementation gap pattern") which allows you the write classes which derive from the generated model classes. Here you can add anything you want. The details are described in a blog of Heiko Behrens. This approach is better suited for large scale modifcations by inheritance.
You may of course mix the two approaches...