January 2019 - forge-issues - Jboss List Archives

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

by Gunnar Morling (Jira)

Gunnar Morling created ROASTER-131: -------------------------------------- Summary: 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 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)

5 years, 11 months

2
1
0 / 0

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

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-130?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-130. ----------------------------------- Resolution: Done > Support parsing of JDK 11 sources > --------------------------------- > > Key: ROASTER-130 > URL: https://issues.jboss.org/browse/ROASTER-130 > Project: Roaster > Issue Type: Enhancement > Components: JDT > Affects Versions: 2.20.6.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Major > Fix For: 2.21.0.Final > > > Update to latest Eclipse JDT -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

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

by George Gastaldi (Jira)

George Gastaldi created ROASTER-130: --------------------------------------- Summary: Support parsing of JDK 11 sources Key: ROASTER-130 URL: https://issues.jboss.org/browse/ROASTER-130 Project: Roaster Issue Type: Enhancement Components: JDT Affects Versions: 2.20.6.Final Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 2.21.0.Final Update to latest Eclipse JDT -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-128) Roaster doesn't check for invalid imports

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-128?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-128. ----------------------------------- > Roaster doesn't check for invalid imports > ----------------------------------------- > > Key: ROASTER-128 > URL: https://issues.jboss.org/browse/ROASTER-128 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.20.0.Final > Environment: Windows 10, Java 8 > Reporter: Kai Müller > Assignee: Kai Müller > Priority: Major > Fix For: 2.20.5.Final, 2.20.6.Final > > > Hi guys, > while working with your library I ran into the following problem. The method setType adds an import if possible and needed. But it doesn't check, if e.g. the class to import is equal to the current class or if another import with the same class name but other package exists. > The provided example leads to the following result: > package testPackage; > import package1.Type; > import package2.Type; > public class Main { > Type field1; > Type field2; > } > This class will not compile and there is no workaround, because there is no way to tell this method NOT to add an import. > In addition, I want to ask you, if you can check the following javadoc of "Importer.Import addImport(Type<?> type)". In this doc it's mentioned that "The method returns the name that can be used inside the code to reference the type". But the returned "Import" object has no such method. I's need to be done via the "resolveType" of the "Importer" object. I would expect, that either the javadoc should be changed or the "Import" get's an additional method. > Thank you very much, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-129. ----------------------------------- Resolution: Done > Improve the javadoc of addImport > -------------------------------- > > Key: ROASTER-129 > URL: https://issues.jboss.org/browse/ROASTER-129 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.20.5.Final > Environment: Windows 10, Java 8 > Reporter: Kai Müller > Assignee: George Gastaldi > Priority: Optional > Fix For: 2.20.6.Final > > > Hello all, > I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)". > Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type". > Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result. > So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped". > Sample code: > public static void main(final String[] args) { > final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class); > final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne"); > final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne"); > System.out.println(imprtOne.getQualifiedName()); > System.out.println(imprtOne.getSimpleName()); > System.out.println(imprtTwo.getQualifiedName()); > System.out.println(imprtTwo.getSimpleName()); > } > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-10. ---------------------------------- Resolution: Done > Auto generated imports when a field type is set causes .java file to not compile. > --------------------------------------------------------------------------------- > > Key: ROASTER-10 > URL: https://issues.jboss.org/browse/ROASTER-10 > Project: Roaster > Issue Type: Bug > Components: API > Affects Versions: 2.2.0.Final > Reporter: Walter Medvedeo > Assignee: George Gastaldi > Priority: Major > Fix For: 2.20.6.Final > > > When we set the Type for a given field using the FieldSource.setType( X ) methods an import is generated automatically. > Under some situations it causes the resulting class to not compile and it's not posible to fix it using the api. > In order to avoid this, and also to be able to modify a given class in a more "safe or controlled" way (for example in cases when we don't want to manage complex refactorings or controlling imports), It's desirable to have setType( X, boolean addImports) method that just change the field type to the provided type name and don't add imports. > e.g: > Given the following declaration: > private org.test.Class1 myField; > myField.setType("org.somepackage.Class2", false) > will produce the following result: > private org.somepackage.Class2 myField; > and: > myField.setType("Class2", false) > will produce the following result: > private Class2 myField. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ] George Gastaldi updated ROASTER-129: ------------------------------------ Fix Version/s: 2.20.6.Final > Improve the javadoc of addImport > -------------------------------- > > Key: ROASTER-129 > URL: https://issues.jboss.org/browse/ROASTER-129 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.20.5.Final > Environment: Windows 10, Java 8 > Reporter: Kai Müller > Assignee: George Gastaldi > Priority: Optional > Fix For: 2.20.6.Final > > > Hello all, > I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)". > Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type". > Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result. > So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped". > Sample code: > public static void main(final String[] args) { > final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class); > final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne"); > final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne"); > System.out.println(imprtOne.getQualifiedName()); > System.out.println(imprtOne.getSimpleName()); > System.out.println(imprtTwo.getQualifiedName()); > System.out.println(imprtTwo.getSimpleName()); > } > Best regards, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-128) Roaster doesn't check for invalid imports

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-128?page=com.atlassian.jira.plugi... ] George Gastaldi updated ROASTER-128: ------------------------------------ Fix Version/s: 2.20.6.Final > Roaster doesn't check for invalid imports > ----------------------------------------- > > Key: ROASTER-128 > URL: https://issues.jboss.org/browse/ROASTER-128 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.20.0.Final > Environment: Windows 10, Java 8 > Reporter: Kai Müller > Assignee: Kai Müller > Priority: Major > Fix For: 2.20.5.Final, 2.20.6.Final > > > Hi guys, > while working with your library I ran into the following problem. The method setType adds an import if possible and needed. But it doesn't check, if e.g. the class to import is equal to the current class or if another import with the same class name but other package exists. > The provided example leads to the following result: > package testPackage; > import package1.Type; > import package2.Type; > public class Main { > Type field1; > Type field2; > } > This class will not compile and there is no workaround, because there is no way to tell this method NOT to add an import. > In addition, I want to ask you, if you can check the following javadoc of "Importer.Import addImport(Type<?> type)". In this doc it's mentioned that "The method returns the name that can be used inside the code to reference the type". But the returned "Import" object has no such method. I's need to be done via the "resolveType" of the "Importer" object. I would expect, that either the javadoc should be changed or the "Import" get's an additional method. > Thank you very much, > Kai -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-10: ----------------------------------- Fix Version/s: 2.20.6.Final (was: 2.x Future) > Auto generated imports when a field type is set causes .java file to not compile. > --------------------------------------------------------------------------------- > > Key: ROASTER-10 > URL: https://issues.jboss.org/browse/ROASTER-10 > Project: Roaster > Issue Type: Bug > Components: API > Affects Versions: 2.2.0.Final > Reporter: Walter Medvedeo > Assignee: George Gastaldi > Priority: Major > Fix For: 2.20.6.Final > > > When we set the Type for a given field using the FieldSource.setType( X ) methods an import is generated automatically. > Under some situations it causes the resulting class to not compile and it's not posible to fix it using the api. > In order to avoid this, and also to be able to modify a given class in a more "safe or controlled" way (for example in cases when we don't want to manage complex refactorings or controlling imports), It's desirable to have setType( X, boolean addImports) method that just change the field type to the provided type name and don't add imports. > e.g: > Given the following declaration: > private org.test.Class1 myField; > myField.setType("org.somepackage.Class2", false) > will produce the following result: > private org.somepackage.Class2 myField; > and: > myField.setType("Class2", false) > will produce the following result: > private Class2 myField. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ] Kai Müller updated ROASTER-10: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/roaster/pull/84 > Auto generated imports when a field type is set causes .java file to not compile. > --------------------------------------------------------------------------------- > > Key: ROASTER-10 > URL: https://issues.jboss.org/browse/ROASTER-10 > Project: Roaster > Issue Type: Bug > Components: API > Affects Versions: 2.2.0.Final > Reporter: Walter Medvedeo > Assignee: George Gastaldi > Priority: Major > Fix For: 2.x Future > > > When we set the Type for a given field using the FieldSource.setType( X ) methods an import is generated automatically. > Under some situations it causes the resulting class to not compile and it's not posible to fix it using the api. > In order to avoid this, and also to be able to modify a given class in a more "safe or controlled" way (for example in cases when we don't want to manage complex refactorings or controlling imports), It's desirable to have setType( X, boolean addImports) method that just change the field type to the provided type name and don't add imports. > e.g: > Given the following declaration: > private org.test.Class1 myField; > myField.setType("org.somepackage.Class2", false) > will produce the following result: > private org.somepackage.Class2 myField; > and: > myField.setType("Class2", false) > will produce the following result: > private Class2 myField. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2019