Home » Modeling » TMF (Xtext) » understanding ImportManager
| understanding ImportManager [message #757889] |
Sun, 20 November 2011 17:48  |
|
Hi
I did some experiments with the
org.eclipse.xtext.xbase.compiler.ImportManager
but I'd like to know whether I got things right
the second constructor is
public ImportManager(boolean organizeImports, JvmDeclaredType thisType)
and I'm not sure whether I got the meaning of the second parameter right.
If I want to generate a Java class (for instance corresponding to a
Greeting EMF model), say
=============================
package mypackage;
class Foo {
... here generated some accesses to Java types ...
}
=============================
If in the generated class I use the Java class otherpackage.Foo
the correct Java class should be
=============================
package mypackage;
class Foo {
... otherpackage.Foo ...
}
=============================
thus I need to avoid to generate something like
=============================
package mypackage;
import otherpackage.Foo;
class Foo {
... otherpackage.Foo ...
}
=============================
since there would be a conflict.
While this class would be correct
=============================
package mypackage;
import otherpackage.Bar;
class Foo {
... Bar ...
}
=============================
I managed to solve this issue thanks to (the wonderful) ImportManager by
passing to the constructor, as a second argument, a JvmGenericType
generated on the fly with the information of the generated Java class, e.g.,
def getJvmType(Greeting greeting) {
val declaredType = TypesFactory::eINSTANCE.createJvmGenericType
declaredType.setSimpleName(greeting.className)
declaredType.setPackageName(greeting.packageName)
declaredType
}
def compile(Greeting greeting) '''
«val importManager = new ImportManager(true, getJvmType(greeting))»
«val mainMethod = compile(greeting, importManager)»
package «greeting.packageName»;
«IF !importManager.imports.empty»
«FOR i : importManager.imports»
import «i»;
«ENDFOR»
«ENDIF»
«mainMethod»
'''
Is this the correct usage/semantics of the second argument to the
constructor of ImportManager?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: understanding ImportManager [message #757890 is a reply to message #757889] |
Sun, 20 November 2011 18:59  |
|
Hi,
yes this looks good for me ;-) and it really does what you mentioned
~Christian
On 2011-11-20 17:48:10 +0000, Lorenzo Bettini said:
> Hi
>
> I did some experiments with the org.eclipse.xtext.xbase.compiler.ImportManager
> but I'd like to know whether I got things right
>
> the second constructor is
>
> public ImportManager(boolean organizeImports, JvmDeclaredType thisType)
>
> and I'm not sure whether I got the meaning of the second parameter right.
>
> If I want to generate a Java class (for instance corresponding to a
> Greeting EMF model), say
>
> =============================
> package mypackage;
>
> class Foo {
> ... here generated some accesses to Java types ...
> }
> =============================
>
> If in the generated class I use the Java class otherpackage.Foo
>
> the correct Java class should be
>
> =============================
> package mypackage;
>
> class Foo {
> ... otherpackage.Foo ...
> }
> =============================
>
> thus I need to avoid to generate something like
>
> =============================
> package mypackage;
>
> import otherpackage.Foo;
>
> class Foo {
> ... otherpackage.Foo ...
> }
> =============================
>
> since there would be a conflict.
>
> While this class would be correct
>
> =============================
> package mypackage;
>
> import otherpackage.Bar;
>
> class Foo {
> ... Bar ...
> }
> =============================
>
>
> I managed to solve this issue thanks to (the wonderful) ImportManager
> by passing to the constructor, as a second argument, a JvmGenericType
> generated on the fly with the information of the generated Java class,
> e.g.,
>
> def getJvmType(Greeting greeting) {
> val declaredType = TypesFactory::eINSTANCE.createJvmGenericType
> declaredType.setSimpleName(greeting.className)
> declaredType.setPackageName(greeting.packageName)
> declaredType
> }
>
> def compile(Greeting greeting) '''
> «val importManager = new ImportManager(true, getJvmType(greeting))»
> «val mainMethod = compile(greeting, importManager)»
> package «greeting.packageName»;
> «IF !importManager.imports.empty»
>
> «FOR i : importManager.imports»
> import «i»;
> «ENDFOR»
> «ENDIF»
>
> «mainMethod»
> '''
>
> Is this the correct usage/semantics of the second argument to the
> constructor of ImportManager?
>
> thanks in advance
> Lorenzo
Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/xtext/
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
| Re: understanding ImportManager [message #757896 is a reply to message #757890] |
Mon, 21 November 2011 17:22 |
|
thanks!
I then documented my experience here:
"Using JVM Types in Xtext 2.1 and the ImportManager"
http://www.rcp-vision.com/?p=1573&lang=en
hope it might help
cheers
Lorenzo
On 11/20/2011 07:59 PM, Christian Dietrich wrote:
> Hi,
>
> yes this looks good for me ;-) and it really does what you mentioned
>
> ~Christian
>
> On 2011-11-20 17:48:10 +0000, Lorenzo Bettini said:
>
>> Hi
>>
>> I did some experiments with the
>> org.eclipse.xtext.xbase.compiler.ImportManager
>> but I'd like to know whether I got things right
>>
>> the second constructor is
>>
>> public ImportManager(boolean organizeImports, JvmDeclaredType thisType)
>>
>> and I'm not sure whether I got the meaning of the second parameter right.
>>
>> If I want to generate a Java class (for instance corresponding to a
>> Greeting EMF model), say
>>
>> =============================
>> package mypackage;
>>
>> class Foo {
>> ... here generated some accesses to Java types ...
>> }
>> =============================
>>
>> If in the generated class I use the Java class otherpackage.Foo
>>
>> the correct Java class should be
>>
>> =============================
>> package mypackage;
>>
>> class Foo {
>> ... otherpackage.Foo ...
>> }
>> =============================
>>
>> thus I need to avoid to generate something like
>>
>> =============================
>> package mypackage;
>>
>> import otherpackage.Foo;
>>
>> class Foo {
>> ... otherpackage.Foo ...
>> }
>> =============================
>>
>> since there would be a conflict.
>>
>> While this class would be correct
>>
>> =============================
>> package mypackage;
>>
>> import otherpackage.Bar;
>>
>> class Foo {
>> ... Bar ...
>> }
>> =============================
>>
>>
>> I managed to solve this issue thanks to (the wonderful) ImportManager
>> by passing to the constructor, as a second argument, a JvmGenericType
>> generated on the fly with the information of the generated Java class,
>> e.g.,
>>
>> def getJvmType(Greeting greeting) {
>> val declaredType = TypesFactory::eINSTANCE.createJvmGenericType
>> declaredType.setSimpleName(greeting.className)
>> declaredType.setPackageName(greeting.packageName)
>> declaredType
>> }
>>
>> def compile(Greeting greeting) '''
>> «val importManager = new ImportManager(true, getJvmType(greeting))»
>> «val mainMethod = compile(greeting, importManager)»
>> package «greeting.packageName»;
>> «IF !importManager.imports.empty»
>>
>> «FOR i : importManager.imports»
>> import «i»;
>> «ENDFOR»
>> «ENDIF»
>>
>> «mainMethod»
>> '''
>>
>> Is this the correct usage/semantics of the second argument to the
>> constructor of ImportManager?
>>
>> thanks in advance
>> Lorenzo
>
>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Goto Forum:
Current Time: Sun Apr 05 02:00:21 GMT 2020
Powered by FUDForum. Page generated in 0.02006 seconds |
Search
Help
Register
Login
Home
