Bugzilla – Full Text Bug Listing
| Summary: | [generator] xpand file encoding not set | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Knut Wannheden <knut.wannheden> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jan, sven.efftinge |
| Version: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
I think the file encoding set on the Xpand generator component (org.eclipse.xpand2.Generator) should also be employed when reading files. The component should thus propagate it to the resource manager as it's created in the inherited AbstractExpressionsUsingWorkflowComponent.getResourceManager() method. Alternatively the fileEncoding field could be lifted up to that class. Any other opinions on this? It seems to be unusual to have two different encodings for the templates and for the to be generated source. So I'm ok with overloading the 'fileEncoding' for both. But I think we should also have a 'templateEncoding' property which can be used in case they are different and which overrides the 'fileEncoding' property for the templates. Since 2.0 we no longer support the generator project. Closing this. |
It seems like the Xpand generator invoked by the example workflow in the generator project sometimes incorrectly detects the file encoding of the Xpand template. This auto detection is performed as the file encoding is not explicitly set. To reproduce the problem (I am running OSX 10.6 in x86_64 with the workspace encoding set to ISO-8859_1): 1. create a new Xtext project (including generator project) with project name "org.xtext.example.config" and language name "org.xtext.example.config.Config" 2. run the GenerateConfig.mwe2 workflow 3. delete the line «EXTENSION templates::Extensions» in Template.xpt 4. run the ConfigGenerator.mwe2 workflow You should now get the following error: 338 [main] ERROR mf.mwe2.launch.runtime.Mwe2Launcher - Problems running workflow workflow.ConfigGenerator: no viable alternative at input '?IMPORT' on line 1 java.lang.RuntimeException: Problems running workflow workflow.ConfigGenerator: no viable alternative at input '?IMPORT' on line 1 at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:82) at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:52) at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.run(Mwe2Launcher.java:74) at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.main(Mwe2Launcher.java:35) Caused by: org.eclipse.internal.xtend.xtend.parser.ParseException: no viable alternative at input '?IMPORT' on line 1 at org.eclipse.internal.xpand2.parser.XpandParseFacade$3.handleError(XpandParseFacade.java:77) at org.eclipse.internal.xpand2.parser.XpandParseFacade$2.reportError(XpandParseFacade.java:66) at org.eclipse.internal.xpand2.parser.XpandParser.template(XpandParser.java:371) at org.eclipse.internal.xpand2.parser.XpandLocationAddingParser.template(XpandLocationAddingParser.java:289) at org.eclipse.internal.xpand2.parser.XpandParseFacade.file(XpandParseFacade.java:44) at org.eclipse.internal.xpand2.parser.XpandParseFacade.file(XpandParseFacade.java:31) at org.eclipse.xpand2.XpandExecutionContextImpl$1.parse(XpandExecutionContextImpl.java:174) at org.eclipse.xtend.expression.ResourceManagerDefaultImpl.loadResource(ResourceManagerDefaultImpl.java:70) at org.eclipse.xpand2.XpandExecutionContextImpl.findTemplate(XpandExecutionContextImpl.java:277) at org.eclipse.xpand2.XpandExecutionContextImpl.findTemplate(XpandExecutionContextImpl.java:270) at org.eclipse.xpand2.XpandExecutionContextImpl.findDefinition(XpandExecutionContextImpl.java:227) at org.eclipse.internal.xpand2.ast.ExpandStatement.invokeDefinition(ExpandStatement.java:233) at org.eclipse.internal.xpand2.ast.ExpandStatement.evaluateInternal(ExpandStatement.java:191) at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41) at org.eclipse.xpand2.Generator.invokeInternal2(Generator.java:333) at org.eclipse.xtend.expression.AbstractExpressionsUsingWorkflowComponent.invokeInternal(AbstractExpressionsUsingWorkflowComponent.java:239) at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:126) at org.eclipse.emf.mwe.core.lib.Mwe2Bridge.invoke(Mwe2Bridge.java:34) at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:201) at org.eclipse.emf.mwe2.runtime.workflow.AbstractCompositeWorkflowComponent.invoke(AbstractCompositeWorkflowComponent.java:31) at org.eclipse.emf.mwe2.runtime.workflow.Workflow.run(Workflow.java:19) at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:80) ... 3 more It appears like the encoding auto detection (in ResourceManagerDefaultImpl) will only fail in very few cases. I managed to work around the problem by adding the following lines inside the ConfigGenerator.mwe2 org.eclipse.xpand2.Generator component: resourceManager = org.eclipse.xtend.expression.ResourceManagerDefaultImpl { fileEncoding = fileEncoding }