|
|
|
Re: Using Java instead of XTend [message #1052706 is a reply to message #1035324] |
Tue, 30 April 2013 12:40 |
|
Hi Steve,
Did changing the variable work for you? I tried it and it only changed the formatter to java and the scopeprovider so I seem to be stuck with xtend files for the generator and validator. Anyone know what I might have setup wrong?
(Adding my mwe2 file incase it helps, what I have done is removed auto-inject at many places since at first I thought that would give me java files)
GenerateIiDsl.mwe2 file
module idainfront.iipax.dsl.GenerateIiDsl
import org.eclipse.emf.mwe.utils.*
import org.eclipse.xtext.generator.*
import org.eclipse.xtext.ui.generator.*
var grammarURI = "classpath:/idainfront/iipax/dsl/IiDsl.xtext"
var fileExtensions = "iidsl"
var projectName = "idainfront.iipax.dsl"
var runtimeProject = "../${projectName}"
var generateXtendStub = false
Workflow {
bean = StandaloneSetup {
scanClassPath = true
platformUri = "${runtimeProject}/.."
// The following two lines can be removed, if Xbase is not used.
registerGeneratedEPackage = "org.eclipse.xtext.xbase.XbasePackage"
registerGenModelFile = "platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel"
}
component = DirectoryCleaner {
directory = "${runtimeProject}/src-gen"
}
component = DirectoryCleaner {
directory = "${runtimeProject}.ui/src-gen"
}
component = Generator {
pathRtProject = runtimeProject
pathUiProject = "${runtimeProject}.ui"
pathTestProject = "${runtimeProject}.tests"
projectNameRt = projectName
projectNameUi = "${projectName}.ui"
language = {
uri = grammarURI
// Java API to access grammar elements (required by several other fragments)
fragment = grammarAccess.GrammarAccessFragment {}
// generates Java API for the generated EPackages
fragment = ecore.EcoreGeneratorFragment {
// referencedGenModels = "
// platform:/resource/org.eclipse.xtext.xbase/model/Xbase.genmodel,
// platform:/resource/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel
// "
}
// the old serialization component
// fragment = parseTreeConstructor.ParseTreeConstructorFragment auto-inject {}
// serializer 2.0
fragment = serializer.SerializerFragment {
generateStub = false
}
// a custom ResourceFactory for use with EMF
fragment = resourceFactory.ResourceFactoryFragment {}
// The antlr parser generator fragment.
fragment = parser.antlr.XtextAntlrGeneratorFragment {
// options = {
// backtrack = true
// }
}
// Xtend-based API for validation
fragment = validation.ValidatorFragment {
// composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"
// composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
}
// old scoping and exporting API
// fragment = scoping.ImportURIScopingFragment auto-inject {}
// fragment = exporting.SimpleNamesFragment auto-inject {}
// scoping and exporting API
fragment = scoping.ImportNamespacesScopingFragment {}
fragment = exporting.QualifiedNamesFragment {}
fragment = builder.BuilderIntegrationFragment {}
// generator API
fragment = generator.GeneratorFragment {generateStub = false}
// formatter API
fragment = formatting.FormatterFragment auto-inject {}
// labeling API
fragment = labeling.LabelProviderFragment {}
// outline API
fragment = outline.OutlineTreeProviderFragment {}
fragment = outline.QuickOutlineFragment {}
// quickfix API
fragment = quickfix.QuickfixProviderFragment {}
// content assist API
fragment = contentAssist.ContentAssistFragment {}
// generates a more lightweight Antlr parser and lexer tailored for content assist
fragment = parser.antlr.XtextAntlrUiGeneratorFragment {}
// generates junit test support classes into Generator#pathTestProject
fragment = junit.Junit4Fragment {}
// project wizard (optional)
// fragment = projectWizard.SimpleProjectWizardFragment auto-inject {
// generatorProjectName = "${projectName}"
// }
// rename refactoring
fragment = refactoring.RefactorElementNameFragment {}
// provides the necessary bindings for java types integration
fragment = types.TypesGeneratorFragment {}
// generates the required bindings only if the grammar inherits from Xbase
fragment = xbase.XbaseGeneratorFragment {}
// provides a preference page for template proposals
fragment = templates.CodetemplatesGeneratorFragment {}
// provides a compare view
fragment = compare.CompareFragment auto-inject {}
}
}
}
|
|
|
|
Re: Using Java instead of XTend [message #1052738 is a reply to message #1052713] |
Tue, 30 April 2013 13:20 |
|
Ok, well, sitting on 2.4 so I will try to learn xtend.
Besides the only thing I really need is to get the filename of my dsl file and make it to a xml, I get as far as "filename.mydsl.xml". I tried to use split and iterator but so far I get nothing
But thanks for the information, I tried to create a class file and it works, it just gets overwritten if I rerun the mwe2 file so it is doable, but since its an annoyingly small thing I am stuck on I think it can be worth to try and learn a little bit of XTend instead of trying to make it into java.
Thanks for the quick reply
Write you later / Mårten
|
|
|
|
|
|
|
|
|
Re: Using Java instead of XTend [message #1092122 is a reply to message #1053003] |
Thu, 22 August 2013 11:01 |
Shelby Moore III Messages: 42 Registered: August 2013 |
Member |
|
|
Steve Kallestad wrote on Wed, 01 May 2013 16:43The easy workaround for me is simply deleting the xtend file, which deletes the auto-generated .java file under src-gen.
I have my own java classes defined with the same names for the validator and scope provider. When I re-run the mwe2 workflow, I simply go and delete those 2 xtend files and everything is fine. I *might* have some hooks declared in the runtime modules, but I don't think I even had to do that.
I appear to be using 2.4.2.v201306120542. Set the var generateXtendStub = false . That change caused the mwe2 workflow to only continue generating .xtend stub for the {ProjectName}Generator.xtend file in the org.xtext.{ProjectFileext}.generator. I can then delete that file as you explained after each re-run of the mwe2 workflow, for a manual work around if I wanted Java source for my code generation.
But I want to use Scala for code generation. Can anyone point me in the direction for learning how to do this?
I realize I might be in the minority, but consider this question applicable to using any JVM language with Xtext for code generation.
Alexei Adamovich wrote on Wed, 01 May 2013 13:31In the situation like this I found the following solution:
since Xtext generates only a stub (written in Xtend), I had got an instance of my Java class there and then had called its method.
So the real work was being done by code written in Java.
Could I call a method in .jar? What do I do to integrate such into the work flow?
[Updated on: Thu, 22 August 2013 14:21] Report message to a moderator
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03723 seconds