January 2019 - forge-issues - Jboss List Archives

[JBoss JIRA] (ROASTER-53) Javadoc could be format on 1 line

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-53?page=com.atlassian.jira.plugin... ] Kai Müller commented on ROASTER-53: ----------------------------------- Hi, Roaster relies on the eclipse jdt core library for formatting. Maybe you could use the FORMATTER_COMMENT_FORMAT_BLOCK_COMMENT preference to avoid formatting of block statements. Otherwise please look through the options defined in org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants. In the case you don't find a good option, please request it the eclipse jdt project. Best regards, Kai > Javadoc could be format on 1 line > --------------------------------- > > Key: ROASTER-53 > URL: https://issues.jboss.org/browse/ROASTER-53 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: Kai Müller > Priority: Minor > > On field, we prefer to have javadoc on 1 line. > {code} > /** Customer id. */ > private String id; > {code} > instead of > {code} > /** > Customer id. > */ > private String id; > {code} > Currently, Roaster doesn't allow us to do it -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-132) Broken interface promise for JavaParser

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-132?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-132. ----------------------------------- Resolution: Rejected > Broken interface promise for JavaParser > --------------------------------------- > > Key: ROASTER-132 > URL: https://issues.jboss.org/browse/ROASTER-132 > Project: Roaster > Issue Type: Bug > Components: API, JDT > Affects Versions: 2.20.8.Final > Reporter: Kai Müller > Priority: Major > > According to the interface JavaParser the methods "create" and "parseUnit" should retunr null of the type is not supported, but the JavaParserImpl throws instead ParserException. > I can think about the following options: > # change the behaviour in JavaParserImpl > # change the interface description, but then make multiple parsers no sense any more if the first is failing with an exception > # basically 2. but catch the exception --> ugly code (my personal opinion) > # Add a "canHandle" method, which returns true if this type of source can be handled > If think, that 1. is the easiest and cleanest solution. We should then maybe enhance the error message thrown if no parser was able to handle the source code. > What do you think? > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-56) Import order

by Nicolas Challut (Jira)

[ https://issues.jboss.org/browse/ROASTER-56?page=com.atlassian.jira.plugin... ] Nicolas Challut commented on ROASTER-56: ---------------------------------------- [~kaijmueller] If you say so, including org.eclipse.jdt.ui is not worth indeed [~gastaldi] I agree, little gain for much effort, won't reopen ^_^ > Import order > ------------ > > Key: ROASTER-56 > URL: https://issues.jboss.org/browse/ROASTER-56 > Project: Roaster > Issue Type: Enhancement > Components: Formatter > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Priority: Optional > Fix For: 2.x Future > > > Roaster formatter should be able to order import -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-132) Broken interface promise for JavaParser

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-132?page=com.atlassian.jira.plugi... ] Kai Müller commented on ROASTER-132: ------------------------------------ Oh, I see. I'll create a PR with an enhancement of the javadoc. > Broken interface promise for JavaParser > --------------------------------------- > > Key: ROASTER-132 > URL: https://issues.jboss.org/browse/ROASTER-132 > Project: Roaster > Issue Type: Bug > Components: API, JDT > Affects Versions: 2.20.8.Final > Reporter: Kai Müller > Priority: Major > > According to the interface JavaParser the methods "create" and "parseUnit" should retunr null of the type is not supported, but the JavaParserImpl throws instead ParserException. > I can think about the following options: > # change the behaviour in JavaParserImpl > # change the interface description, but then make multiple parsers no sense any more if the first is failing with an exception > # basically 2. but catch the exception --> ugly code (my personal opinion) > # Add a "canHandle" method, which returns true if this type of source can be handled > If think, that 1. is the easiest and cleanest solution. We should then maybe enhance the error message thrown if no parser was able to handle the source code. > What do you think? > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-56) Import order

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-56?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-56. ---------------------------------- Resolution: Won't Do Closing as won't do. Reopen if necessary > Import order > ------------ > > Key: ROASTER-56 > URL: https://issues.jboss.org/browse/ROASTER-56 > Project: Roaster > Issue Type: Enhancement > Components: Formatter > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Priority: Optional > Fix For: 2.x Future > > > Roaster formatter should be able to order import -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-56) Import order

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-56?page=com.atlassian.jira.plugin... ] George Gastaldi commented on ROASTER-56: ---------------------------------------- I'd rather not add a dependency on the org.eclipse.jdt.ui package. This would need to be implemented as a new API in Roaster, but I am not sure it's worth the effort for so little gain > Import order > ------------ > > Key: ROASTER-56 > URL: https://issues.jboss.org/browse/ROASTER-56 > Project: Roaster > Issue Type: Enhancement > Components: Formatter > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Priority: Optional > Fix For: 2.x Future > > > Roaster formatter should be able to order import -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-132) Broken interface promise for JavaParser

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-132?page=com.atlassian.jira.plugi... ] George Gastaldi commented on ROASTER-132: ----------------------------------------- ParserException is only thrown if the data cannot be parsed. Null is returned ONLY if the requested type is not supported by the JavaParser implementation. Perhaps the Javadoc needs to be more clear about this. > Broken interface promise for JavaParser > --------------------------------------- > > Key: ROASTER-132 > URL: https://issues.jboss.org/browse/ROASTER-132 > Project: Roaster > Issue Type: Bug > Components: API, JDT > Affects Versions: 2.20.8.Final > Reporter: Kai Müller > Priority: Major > > According to the interface JavaParser the methods "create" and "parseUnit" should retunr null of the type is not supported, but the JavaParserImpl throws instead ParserException. > I can think about the following options: > # change the behaviour in JavaParserImpl > # change the interface description, but then make multiple parsers no sense any more if the first is failing with an exception > # basically 2. but catch the exception --> ugly code (my personal opinion) > # Add a "canHandle" method, which returns true if this type of source can be handled > If think, that 1. is the easiest and cleanest solution. We should then maybe enhance the error message thrown if no parser was able to handle the source code. > What do you think? > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-132) Broken interface promise for JavaParser

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-132?page=com.atlassian.jira.plugi... ] Kai Müller updated ROASTER-132: ------------------------------- Priority: Major (was: Minor) > Broken interface promise for JavaParser > --------------------------------------- > > Key: ROASTER-132 > URL: https://issues.jboss.org/browse/ROASTER-132 > Project: Roaster > Issue Type: Bug > Components: API, JDT > Affects Versions: 2.20.8.Final > Reporter: Kai Müller > Priority: Major > > According to the interface JavaParser the methods "create" and "parseUnit" should retunr null of the type is not supported, but the JavaParserImpl throws instead ParserException. > I can think about the following options: > # change the behaviour in JavaParserImpl > # change the interface description, but then make multiple parsers no sense any more if the first is failing with an exception > # basically 2. but catch the exception --> ugly code (my personal opinion) > # Add a "canHandle" method, which returns true if this type of source can be handled > If think, that 1. is the easiest and cleanest solution. We should then maybe enhance the error message thrown if no parser was able to handle the source code. > What do you think? > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-56) Import order

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-56?page=com.atlassian.jira.plugin... ] Kai Müller commented on ROASTER-56: ----------------------------------- I took some research and it seems this is not supported by org.eclipse.jdt.core, but of org.eclipse.jdt.ui. I'm not sure if it make sense to include such a big lib only for ordering purpose. Source: * https://www.eclipse.org/forums/index.php/t/79512/ * https://www.eclipse.org/forums/index.php?t=msg&th=82688/ * https://www.eclipse.org/forums/index.php/t/75991/ [~gastaldi]: Do you think this worth a own implementation? > Import order > ------------ > > Key: ROASTER-56 > URL: https://issues.jboss.org/browse/ROASTER-56 > Project: Roaster > Issue Type: Enhancement > Components: Formatter > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Priority: Optional > Fix For: 2.x Future > > > Roaster formatter should be able to order import -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-132) Broken interface promise for JavaParser

by Kai Müller (Jira)

Kai Müller created ROASTER-132: ---------------------------------- Summary: Broken interface promise for JavaParser Key: ROASTER-132 URL: https://issues.jboss.org/browse/ROASTER-132 Project: Roaster Issue Type: Bug Components: API, JDT Affects Versions: 2.20.8.Final Reporter: Kai Müller According to the interface JavaParser the methods "create" and "parseUnit" should retunr null of the type is not supported, but the JavaParserImpl throws instead ParserException. I can think about the following options: # change the behaviour in JavaParserImpl # change the interface description, but then make multiple parsers no sense any more if the first is failing with an exception # basically 2. but catch the exception --> ugly code (my personal opinion) # Add a "canHandle" method, which returns true if this type of source can be handled If think, that 1. is the easiest and cleanest solution. We should then maybe enhance the error message thrown if no parser was able to handle the source code. What do you think? Best regards, Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2019