January 2019 - forge-issues - Jboss List Archives

[JBoss JIRA] (ROASTER-4) Having Parameterize interface bit more typed

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-4?page=com.atlassian.jira.plugin.... ] Kai Müller commented on ROASTER-4: ---------------------------------- Sure. I did some testing and it seems that addTypeVariable is the right method to use this. The following should be implemented * addTypeVariable (Class) * addTypeVariable().setName(Class) What do you think? The name is no the best, but it should be okay. Else I could add some default methods which act as an alias. I discovered a feature gap, that wildcards (?) are not supported. To enable this, we need to use https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%.... If you think that's feasible, I'll implement this in the next time. > Having Parameterize interface bit more typed > -------------------------------------------- > > Key: ROASTER-4 > URL: https://issues.jboss.org/browse/ROASTER-4 > Project: Roaster > Issue Type: Feature Request > Components: API > Affects Versions: 2.1.0.Final > Reporter: Antonio Goncalves > Priority: Major > Fix For: 2.x Future > > > For a constraint, I need to implement a parametrize interface like this : > {code} > public class MaxValidatorForString implements ConstraintValidator<Max, Number> { > {code} > The only way I could find is by passing a String : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addImport(ConstraintValidator.class); > javaClass.addInterface("ConstraintValidator<Max, Number>"); > {code} > It's a shame because with {{addInterface(Class)}}, it does the import automatically and things are more typed. But I cannot add types : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addInterface(ConstraintValidator.class); > {code} > It would be good to have something like : > {code} > javaClass.addInterface(ConstraintValidator.class).addType(Max.class).addType(Number.class); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-133) Revisit Import#getQualifiedName

by Kai Müller (Jira)

Kai Müller created ROASTER-133: ---------------------------------- Summary: Revisit Import#getQualifiedName Key: ROASTER-133 URL: https://issues.jboss.org/browse/ROASTER-133 Project: Roaster Issue Type: Task Reporter: Kai Müller Revisit the getQualifiedName logic in the import since it returns the package for wildcard imports which is not very nice. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-23) Forge JavaParser does not support Wildcard Imports "org.jboss.forge.*"

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-23?page=com.atlassian.jira.plugin... ] Kai Müller updated ROASTER-23: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/roaster/pull/95 I added a check, if only one wildcard is import is used. In this case we are able to resolve the name > Forge JavaParser does not support Wildcard Imports "org.jboss.forge.*" > ---------------------------------------------------------------------- > > Key: ROASTER-23 > URL: https://issues.jboss.org/browse/ROASTER-23 > Project: Roaster > Issue Type: Enhancement > Reporter: Lincoln Baxter III > Priority: Major > Fix For: 2.x Future > > > The JavaParser Annotation.getQualifiedName() will return "Column" instead of "javax.persistence.Column" for the following example class scenario. It should be able to understand the wildcard, given the proper metadata: > {code}package demo.entities; > import javax.persistence.*; > @Entity > public class Contact implements java.io.Serializable { > @Id > private @GeneratedValue(strategy = GenerationType.AUTO) > @Column(name = "id", updatable = false, nullable = false) > Long id = null; > @Version > private @Column(name = "version") > int version = 0; > public Long getId() { > return this.id; > } > public void setId(final Long id) { > this.id = id; > } > public int getVersion() { > return this.version; > } > public void setVersion(final int version) { > this.version = version; > } > @Override > public boolean equals(Object that) { > if (this == that) { > return true; > } > if (that == null) { > return false; > } > if (getClass() != that.getClass()) { > return false; > } > if (id != null) { > return id.equals(((Contact) that).id); > } > return super.equals(that); > } > @Override > public int hashCode() { > if (id != null) { > return id.hashCode(); > } > return super.hashCode(); > } > private String name; > public String getName() { > return this.name; > } > public void setName(final String name) { > this.name = name; > } > public String toString() { > return "" + name; > } > }{code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-23) Forge JavaParser does not support Wildcard Imports "org.jboss.forge.*"

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-23?page=com.atlassian.jira.plugin... ] Kai Müller reassigned ROASTER-23: --------------------------------- Assignee: Kai Müller > Forge JavaParser does not support Wildcard Imports "org.jboss.forge.*" > ---------------------------------------------------------------------- > > Key: ROASTER-23 > URL: https://issues.jboss.org/browse/ROASTER-23 > Project: Roaster > Issue Type: Enhancement > Reporter: Lincoln Baxter III > Assignee: Kai Müller > Priority: Major > Fix For: 2.x Future > > > The JavaParser Annotation.getQualifiedName() will return "Column" instead of "javax.persistence.Column" for the following example class scenario. It should be able to understand the wildcard, given the proper metadata: > {code}package demo.entities; > import javax.persistence.*; > @Entity > public class Contact implements java.io.Serializable { > @Id > private @GeneratedValue(strategy = GenerationType.AUTO) > @Column(name = "id", updatable = false, nullable = false) > Long id = null; > @Version > private @Column(name = "version") > int version = 0; > public Long getId() { > return this.id; > } > public void setId(final Long id) { > this.id = id; > } > public int getVersion() { > return this.version; > } > public void setVersion(final int version) { > this.version = version; > } > @Override > public boolean equals(Object that) { > if (this == that) { > return true; > } > if (that == null) { > return false; > } > if (getClass() != that.getClass()) { > return false; > } > if (id != null) { > return id.equals(((Contact) that).id); > } > return super.equals(that); > } > @Override > public int hashCode() { > if (id != null) { > return id.hashCode(); > } > return super.hashCode(); > } > private String name; > public String getName() { > return this.name; > } > public void setName(final String name) { > this.name = name; > } > public String toString() { > return "" + name; > } > }{code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-4) Having Parameterize interface bit more typed

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-4?page=com.atlassian.jira.plugin.... ] George Gastaldi commented on ROASTER-4: --------------------------------------- [~kaijmueller] yeah, I think that makes sense. Want to give it a shot? > Having Parameterize interface bit more typed > -------------------------------------------- > > Key: ROASTER-4 > URL: https://issues.jboss.org/browse/ROASTER-4 > Project: Roaster > Issue Type: Feature Request > Components: API > Affects Versions: 2.1.0.Final > Reporter: Antonio Goncalves > Priority: Major > Fix For: 2.x Future > > > For a constraint, I need to implement a parametrize interface like this : > {code} > public class MaxValidatorForString implements ConstraintValidator<Max, Number> { > {code} > The only way I could find is by passing a String : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addImport(ConstraintValidator.class); > javaClass.addInterface("ConstraintValidator<Max, Number>"); > {code} > It's a shame because with {{addInterface(Class)}}, it does the import automatically and things are more typed. But I cannot add types : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addInterface(ConstraintValidator.class); > {code} > It would be good to have something like : > {code} > javaClass.addInterface(ConstraintValidator.class).addType(Max.class).addType(Number.class); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

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

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-53?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-53. ---------------------------------- > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-126) Format options not taken into account

by George Gastaldi (Jira)

[ https://issues.jboss.org/browse/ROASTER-126?page=com.atlassian.jira.plugi... ] George Gastaldi closed ROASTER-126. ----------------------------------- > Format options not taken into account > ------------------------------------- > > Key: ROASTER-126 > URL: https://issues.jboss.org/browse/ROASTER-126 > Project: Roaster > Issue Type: Bug > Components: Formatter > Affects Versions: 2.20.0.Final > Reporter: Luca Burgazzoli > Assignee: Kai Müller > Priority: Minor > > I'm doing some small experiments with Forge Roaster and I'm unable to get some formatting options taken into account. > My code and the result is here: https://gist.github.com/lburgazzoli/115377c3887972696f77db3a71fef85f > As you can notice, I configured some properties so that the code should wrap at column 120 and it should use spaces instead of tabs but my set-up is ignored and the resulting code is still formatted with some defaults. > I set the formatting properties with: > {code:java} > properties.put(DefaultCodeFormatterConstants.FORMATTER_LINE_SPLIT, "120") > properties.put(DefaultCodeFormatterConstants.FORMATTER_TAB_CHAR, "space") > properties.put(DefaultCodeFormatterConstants.FORMATTER_TAB_SIZE, "4") > {code} > The behaviour does not change if I use constants without the shaded package value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-4) Having Parameterize interface bit more typed

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-4?page=com.atlassian.jira.plugin.... ] Kai Müller commented on ROASTER-4: ---------------------------------- What do you think about to enrich the GenericCapableSource interface with this functionallity? Maybe the following method could be add: * addType(String) * addType(Class) BR, Kai > Having Parameterize interface bit more typed > -------------------------------------------- > > Key: ROASTER-4 > URL: https://issues.jboss.org/browse/ROASTER-4 > Project: Roaster > Issue Type: Feature Request > Components: API > Affects Versions: 2.1.0.Final > Reporter: Antonio Goncalves > Priority: Major > Fix For: 2.x Future > > > For a constraint, I need to implement a parametrize interface like this : > {code} > public class MaxValidatorForString implements ConstraintValidator<Max, Number> { > {code} > The only way I could find is by passing a String : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addImport(ConstraintValidator.class); > javaClass.addInterface("ConstraintValidator<Max, Number>"); > {code} > It's a shame because with {{addInterface(Class)}}, it does the import automatically and things are more typed. But I cannot add types : > {code} > final JavaClassSource javaClass = Roaster.create(JavaClassSource.class); > javaClass.setName("MaxValidatorForString"); > javaClass.addInterface(ConstraintValidator.class); > {code} > It would be good to have something like : > {code} > javaClass.addInterface(ConstraintValidator.class).addType(Max.class).addType(Number.class); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-126) Format options not taken into account

by Kai Müller (Jira)

[ https://issues.jboss.org/browse/ROASTER-126?page=com.atlassian.jira.plugi... ] Kai Müller resolved ROASTER-126. -------------------------------- Assignee: Kai Müller Resolution: Cannot Reproduce Hi, I cannot reproduce the issue with the latest version of Roaster. If I change the FORMATTER_LINE_SPLIT, the line splits either before or at the 80th column/character(including whitespace). Best regards, Kai > Format options not taken into account > ------------------------------------- > > Key: ROASTER-126 > URL: https://issues.jboss.org/browse/ROASTER-126 > Project: Roaster > Issue Type: Bug > Components: Formatter > Affects Versions: 2.20.0.Final > Reporter: Luca Burgazzoli > Assignee: Kai Müller > Priority: Minor > > I'm doing some small experiments with Forge Roaster and I'm unable to get some formatting options taken into account. > My code and the result is here: https://gist.github.com/lburgazzoli/115377c3887972696f77db3a71fef85f > As you can notice, I configured some properties so that the code should wrap at column 120 and it should use spaces instead of tabs but my set-up is ignored and the resulting code is still formatted with some defaults. > I set the formatting properties with: > {code:java} > properties.put(DefaultCodeFormatterConstants.FORMATTER_LINE_SPLIT, "120") > properties.put(DefaultCodeFormatterConstants.FORMATTER_TAB_CHAR, "space") > properties.put(DefaultCodeFormatterConstants.FORMATTER_TAB_SIZE, "4") > {code} > The behaviour does not change if I use constants without the shaded package value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2019