Home » Modeling » TMF (Xtext) » JvmType, add additional Types, that will be generated, but are not there YET
| JvmType, add additional Types, that will be generated, but are not there YET [message #1007194] |
Mon, 04 February 2013 21:34  |
 M. Herrmann
Messages: 25
Registered: March 2010 |
Junior Member |
|
|
Hello Xtext community,
I really appreciate your help concerning the following problem
I am developing a DSL with XText, that makes use of
import "http://www.eclipse.org/xtext/common/JavaVMTypes" as jvmTypes;
and some part of my language definition looks like this (simplified):
Rule:
'insertClasses' '{'
insertClasses +=[jvmTypes::JvmType|QUALIFIED_ID] (',' insertClasses +=[jvmTypes::JvmType|QUALIFIED_ID])*
'}';
I use Xtend to generate java classes from the DSL.
The problem I am facing is:
In the "insertClasses" part of my DSL, the user should be able to also use the classes that WILL be generated, but are not there YET (the fully qualified class names are deductable from the rest of the DSL file).
At the moment this is some kind of chicken / egg problem.
Without the class beeing generated the DSLfile will fail to build, and if it fails to build, the classes will not be generated.
Is there some way to "trick" the jvmTypes to also display my generated classes (code completion) even if they are not there YET?
And how can i make the dsl file to compile, even though the classes are not there YET?
It should still display errors if the user uses a fully qualified class name of a class, that is neither present in the classpath nor one of the known generated classes.
Thanks for your help in advance
Markus
|
|
|
| Re: JvmType, add additional Types, that will be generated, but are not there YET [message #1007222 is a reply to message #1007194] |
Tue, 05 February 2013 06:16  |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Things like Xcore and Xtend have similar concerns. As long as you infer
at least the class/interface that you will generate later and do so
during the call to your derived
org.eclipse.xtext.resource.IDerivedStateComputer.installDerivedState(DerivedStateAwareResource,
boolean) for preLinkingPhase true and ensure that those are part of your
resource's descriptions (they should be as long as you create them
somewhere in the resource's contents), any other resource should be able
to link to these classes as if they've already been generated.
On 04/02/2013 10:34 PM, M. Herrmann wrote:
> Hello Xtext community,
>
> I really appreciate your help concerning the following problem
>
> I am developing a DSL with XText, that makes use of
> import "http://www.eclipse.org/xtext/common/JavaVMTypes" as jvmTypes;
>
>
> and some part of my language definition looks like this (simplified):
>
>
> Rule:
> 'insertClasses' '{'
> insertClasses +=[jvmTypes::JvmType|QUALIFIED_ID] (',' insertClasses
> +=[jvmTypes::JvmType|QUALIFIED_ID])*
> '}';
>
>
> I use Xtend to generate java classes from the DSL.
>
> The problem I am facing is:
>
> In the "insertClasses" part of my DSL, the user should be able to also
> use the classes that WILL be generated, but are not there YET (the
> fully qualified class names are deductable from the rest of the DSL
> file).
> At the moment this is some kind of chicken / egg problem.
> Without the class beeing generated the DSLfile will fail to build, and
> if it fails to build, the classes will not be generated.
>
> Is there some way to "trick" the jvmTypes to also display my generated
> classes (code completion) even if they are not there YET?
> And how can i make the dsl file to compile, even though the classes
> are not there YET?
> It should still display errors if the user uses a fully qualified
> class name of a class, that is neither present in the classpath nor
> one of the known generated classes.
>
> Thanks for your help in advance
>
>
> Markus
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: JvmType, add additional Types, that will be generated, but are not there YET [message #1007257 is a reply to message #1007194] |
Tue, 05 February 2013 09:35 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
As Ed says, try to use Xbase. As an introduction I suggest reading
http://www.eclipse.org/Xtext/documentation.html#JvmDomainmodel.
As you generate Java, consider replacing the code generation with JVM
model inferrence. It will provide fully integrated tooling for Java and
your DSL out-of-the box.
Am 04.02.13 22:34, schrieb M. Herrmann:
> Hello Xtext community,
>
> I really appreciate your help concerning the following problem
>
> I am developing a DSL with XText, that makes use of
> import "http://www.eclipse.org/xtext/common/JavaVMTypes" as jvmTypes;
>
>
> and some part of my language definition looks like this (simplified):
>
>
> Rule:
> 'insertClasses' '{'
> insertClasses +=[jvmTypes::JvmType|QUALIFIED_ID] (',' insertClasses
> +=[jvmTypes::JvmType|QUALIFIED_ID])*
> '}';
>
>
> I use Xtend to generate java classes from the DSL.
>
> The problem I am facing is:
>
> In the "insertClasses" part of my DSL, the user should be able to also
> use the classes that WILL be generated, but are not there YET (the fully
> qualified class names are deductable from the rest of the DSL file).
> At the moment this is some kind of chicken / egg problem.
> Without the class beeing generated the DSLfile will fail to build, and
> if it fails to build, the classes will not be generated.
>
> Is there some way to "trick" the jvmTypes to also display my generated
> classes (code completion) even if they are not there YET?
> And how can i make the dsl file to compile, even though the classes are
> not there YET?
> It should still display errors if the user uses a fully qualified class
> name of a class, that is neither present in the classpath nor one of the
> known generated classes.
>
> Thanks for your help in advance
>
>
> Markus
>
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: JvmType, add additional Types, that will be generated, but are not there YET [message #1007439 is a reply to message #1007257] |
Tue, 05 February 2013 21:06 |
M. Herrmann
Messages: 25
Registered: March 2010 |
Junior Member |
|
|
Tanks for the quick answers.
I looked at the tutorial you linked (about the JvmDomainmodel).
In the tutorial it says "Xbase relies on a small runtime library on the class path".
This might be a blocker for me.
But I have some more question:
In my domain model one model element must yield more than one class / interface.
So I thought in the AbstractModelInferrer in the "infer" method I call "accept" on the acceptor more than once (once for each class / interface i want to generate from the domain model object).
Is that correct?
Because i favor the "generation gap pattern" for the generated code (the user has to manually add code), some classes need to be generated into the "src" folder (only if the do not exist, "generate once") and some classes have to be genrated to the "src-gen" folder.
I also need to generate some additional files (like property files).
Is there a way to control where the java files will be placed? "src" or "src-gen"?
Edit: trying to answer the last question (generating to different source folders) myself:
I probably need to
- create a IOutputConfigurationProvider that configures the output locations (i did that in my old project already)
- replace the default JvmModelGenerator with my own custom implementation so that it considers the different ouput locations
Right? Or is there a better way?
[Updated on: Tue, 05 February 2013 21:38] Report message to a moderator |
|
|
| Re: JvmType, add additional Types, that will be generated, but are not there YET [message #1007521 is a reply to message #1007439] |
Wed, 06 February 2013 10:19 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Answers inline
Am 05.02.13 22:06, schrieb M. Herrmann:
> Tanks for the quick answers.
> I looked at the tutorial you linked (about the JvmDomainmodel).
>
> In the tutorial it says "Xbase relies on a small runtime library on the
> class path".
> This might be a blocker for me.
That's a pity. The lib contains Guava, Google Inject and some library
classes that provide useful extension methods, e.g. for dealing with
collections, as well as the implementation for all operators.
> But I have some more question:
>
> In my domain model one model element must yield more than one class /
> interface.
> So I thought in the AbstractModelInferrer in the "infer" method I call
> "accept" on the acceptor more than once (once for each class / interface
> i want to generate from the domain model object).
> Is that correct?
Correct
> Because i favor the "generation gap pattern" for the generated code (the
> user has to manually add code), some classes need to be generated into
> the "src" folder (only if the do not exist, "generate once") and some
> classes have to be genrated to the "src-gen" folder.
> I also need to generate some additional files (like property files). Is
> there a way to control where the java files will be placed? "src" or
> "src-gen"?
>
I suppose you've implemented the IGenerator interface. The second
argument in
org.eclipse.xtext.generator.IFileSystemAccess.generateFile(String,
String, CharSequence)
describes the OutputConfiguration, that encapsulates the folder amongst
other parameters. Bind your own IOutputConfigurationProvider to provide
the ones you need.
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: JvmType, add additional Types, that will be generated, but are not there YET [message #1021956 is a reply to message #1007521] |
Thu, 21 March 2013 01:35 |
Jean-Luc Amitousa Mankoy
Messages: 1
Registered: March 2013 |
Junior Member |
|
|
Imagine you have a Class named my.package.MyClass outside your xtext project. If you want to generate something like this:
import my.package.MyClass;
public GenerateFromXtext {
private MyClass mc;
}
You can do this in the jvmmodelinfer file:
infer(model, acceptor, preIndexing){
var JvmGenericType mcType= model.toClass("MyClass")
acceptor.accept(mcType).initializeLater([setPackageName= "my.package"])
acceptor.accept(model.toClass("GeneratedFromXtext"))
.initializeLater([
fields += model.toField("mc", newTypeRef(mcType))
])
}
After the generation, you put the generated file into your extern project which containing the none-foo class MyClass.
[Added after edit:]
Assuming a model like this:
Model:
type=UserType name=ID
;
UserType:
typeName=ID
;
You can refer to the userType by the same way:
infer(model, acceptor, preIndexing){
var JvmGenericType userType= model.toClass(model.type.typeName)
acceptor.accept(userType).initializeLater([
//you put here what suppose to be in the class
])
acceptor.accept(model.toClass("GeneratedFromXtext"))
.initializeLater([
fields += model.toField("mc", newTypeRef(userType))
])
}
[Not tested: but i think that work too]
And if the userType is not already inferred but you need it for infer an other userType, get all userTypes name, get their jvmGenericType with model.toClass(model.type.typeName). After this you can refer before infer them. It's like a declaration before definition in C langage.
[Updated on: Fri, 29 March 2013 05:14] Report message to a moderator |
|
|
Goto Forum:
Current Time: Sun Nov 10 17:55:26 GMT 2024
Powered by FUDForum. Page generated in 0.02846 seconds |
] 
Search
Help
Register
Login
Home
