[ https://issues.jboss.org/browse/ROASTER-131?page=com.atlassian.jira.plugi... ] Gunnar Morling edited comment on ROASTER-131 at 1/21/19 4:25 AM: ----------------------------------------------------------------- Hey [~gastaldi], thanks a lot for the quick help! Unfortunately, things are still not quite working as they should. It now applies the given XML settings file (that's great!), but then it doesn't do any (expected) reformatting. I debugged a bit and the reason is this: * No source level (option "org.eclipse.jdt.core.compiler.source") is given in the XML file; hence in {{DefaultCodeFormatter#getDefaultCompilerOptions()}} it applies 1.3 as a default value * This makes the internal parse fail when using newer language features, e.g. static imports * Hence no {{TextEdit}} is returned from JDT's {{CodeFormatter}} and Roaster's {{Formatter}} ends up doing nothing To make things work, I could set the property in the formatter XML file ({{<setting id="org.eclipse.jdt.core.compiler.source" value="1.8"/>}}), but I don't think that this is a viable approach. When re-exporting the XML file from Eclipse, it won't contain that property. So I think two things should be done: * Add a new option to the roaster script that accepts a language level and passes it on to the Eclipse formatter; that option would be mandatory when using the XML configuration * Log a warning if the formatting failed; the current silent failing is tricky to spot was (Author: gunnar.morling): Hey [~gastaldi], thanks a lot for the quick help! Unfortunately, things are still not quite working as they should. It now applies the given XML settings file (that's great!), but then it doesn't do any (expected) reformatting. I debugged a bit and the reason is this: * No source level (option "org.eclipse.jdt.core.compiler.source") is given in the XML file; hence in {{DefaultCodeFormatter#getDefaultCompilerOptions()}} it applies 1.3 as a default value * This makes the internal parse fail when using newer language features, e.g. static imports * Hence no {{TextEdit}} is returned from JDT's {{CodeFormatter}} and Roaster's {{Formatter}} ends up doing nothing To make things work, I could set the property in the formatter XML file ({{<setting id="org.eclipse.jdt.core.compiler.source" value="1.8"/>}}), but I don't think that this is a viable approach. When re-exporting the XML file from Eclipse, it won't contain that property. So I think two things should be done: * Add a new option to the roaster script that accepts a language level and passes it on to the Eclipse formatter * Log a warning if the formatting failed; the current silent failure are tricky to spot -- This message was sent by Atlassian Jira (v7.12.1#712002)