January 2019 - forge-issues - Jboss List Archives

[JBoss JIRA] (ROASTER-106) Roaster is slow when parsing some classes

by Nicolas Challut (Jira)

[ https://issues.jboss.org/browse/ROASTER-106?page=com.atlassian.jira.plugi... ] Nicolas Challut commented on ROASTER-106: ----------------------------------------- [~kaijmueller] I do not work anymore with ROASTER daily so I didn't try the latest version. But today I launch this test with 2.18.7 and 2.20.6 and you're right. With the old version, the test times out but with the new one, it takes half a second. So yes, latests optimizations improved the performance, thank you :) > … [View More]

6 years, 2 months

1
0
0 / 0

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

by Gunnar Morling (Jira)

[ 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 … [View More]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) [View Less]

6 years, 2 months

1
0
0 / 0

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

by Gunnar Morling (Jira)

[ 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 … [View More]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 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 applying 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) [View Less]

6 years, 2 months

1
0
0 / 0

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

by Gunnar Morling (Jira)

[ https://issues.jboss.org/browse/ROASTER-131?page=com.atlassian.jira.plugi... ] Gunnar Morling reopened ROASTER-131: ------------------------------------ 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 … [View More]

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-130) Support parsing of JDK 11 sources

by Anonymous (Jira)

[ https://issues.jboss.org/browse/ROASTER-130?page=com.atlassian.jira.plugi... ] Issue was automatically transitioned when George Gastaldi created pull request #91 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Support parsing of JDK 11 sources > --------------------------------- > > Key: ROASTER-130 > URL: https://issues.jboss.org/browse/… [View More]

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-130) Support parsing of JDK 11 sources

by Anonymous (Jira)

[ https://issues.jboss.org/browse/ROASTER-130?page=com.atlassian.jira.plugi... ] Issue was automatically transitioned when George Gastaldi merged pull request #90 in GitHub ------------------------------------------------------------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Support parsing of JDK 11 sources > --------------------------------- > > Key: ROASTER-130 > URL: https://… [View More]

6 years, 2 months

1
0
0 / 0

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

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-131?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-131. ----------------------------------- Resolution: Done Version 2.20.7.Final now supports specifying eclipse XML files as parameter. Reopen if the problem persists > Config file not applied when using CLI > -------------------------------------- > > Key: ROASTER-131 > URL: https://issues.jboss.org/browse/ROASTER-131 > … [View More]

6 years, 2 months

1
0
0 / 0

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

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-131?page=com.atlassian.jira.plugi... ] George Gastaldi updated ROASTER-131: ------------------------------------ Fix Version/s: 2.20.7.Final > 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 … [View More]

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-117) Cannot set supertype with nested generics

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-117?page=com.atlassian.jira.plugi... ] George Gastaldi updated ROASTER-117: ------------------------------------ Fix Version/s: 2.20.7.Final (was: 2.21.0.Final) > Cannot set supertype with nested generics > ----------------------------------------- > > Key: ROASTER-117 > URL: https://issues.jboss.org/browse/ROASTER-117 > Project: Roaster > Issue Type:… [View More]

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-117) Cannot set supertype with nested generics

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-117?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-117. ----------------------------------- Resolution: Done > Cannot set supertype with nested generics > ----------------------------------------- > > Key: ROASTER-117 > URL: https://issues.jboss.org/browse/ROASTER-117 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects … [View More]

6 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2019