Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
M. Herrmann is currently offline M. HerrmannFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
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
>
>
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 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 658
Registered: July 2009
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
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 Go to previous messageGo to next message
M. Herrmann is currently offline M. HerrmannFriend
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 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 658
Registered: July 2009
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
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 Go to previous message
Jean-Luc Amitousa Mankoy is currently offline Jean-Luc Amitousa MankoyFriend
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

Previous Topic:Combining existing Model and own Grammar
Next Topic:QualifiedNameProvider-Question
Goto Forum:
  


Current Time: Sun Dec 21 21:41:12 GMT 2014

Powered by FUDForum. Page generated in 0.01690 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software