[forge-issues] [JBoss JIRA] (ROASTER-131) Config file not applied when using CLI

[Gunnar Morling (Jira)]

    [ https://issues.jboss.org/browse/ROASTER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684574#comment-13684574 ] 

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

> Config file not applied when using CLI
> --------------------------------------
>
>                 Key: ROASTER-131
>                 URL: https://issues.jboss.org/browse/ROASTER-131
>             Project: Roaster
>          Issue Type: Enhancement
>            Reporter: Gunnar Morling
>            Assignee: George Gastaldi
>            Priority: Major
>             Fix For: 2.20.7.Final
>
>
> I'm using the CLI (roaster.sh) to format some source files, but it doesn't apply the given Eclipse formatter file (passed via -c). As per roaster's output it should have worked, but clearly it's using a different configuration, e.g. in my XML config file I'm mandating to only use spaces for indentation, whereas the file is indented with tabs after roaster ran. Note the config itself can't be the problem, as it's applied as expected when ran through Spotless.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)