November 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-1271) Adding code conventions to generated code

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1271?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1271: -------------------------------------- Affects Version/s: 2.0.0.Alpha14 > Adding code conventions to generated code > ----------------------------------------- > > Key: FORGE-1271 > URL: https://issues.jboss.org/browse/FORGE-1271 > Project: Forge > Issue Type: Feature Request > Components: Resources API, Scaffold > Affects Versions: 2.0.0.Alpha14 > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > Discussion on : https://community.jboss.org/message/842429 > Developers look at Forge as the "way to write Java EE code" or if you like "if those guys write code like this, then we should". > I am digging into some details of the generated code (I am writing a blog about several architectural styles starting with Forge) and I feel coding convention should be homogenized. I know extensions are written by different individuals, but some basic coding conventions should be applied. For example, when you generate a web app with REST and Faces scaffolding, you get some difference : > * Faces Backing Bean use query builder (e.g {{getAll}} method is {{entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();}} and > * REST Endpoint use dynamic queries (the {{listAll}} method is {{"SELECT DISTINCT b FROM Book b ORDER BY b.id"))}} > Method names are different and do the same : > * JSF : {{getAll}} > * REST : {{listAll}} > Attributes > * {{private EntityManager em;}} > * {{private EntityManager entityManager;}} // em would be better > Or the use of {{this}} keyword (JSF beans use {{this.entityManager}} instead of directly {{em}} in REST) > And there are several examples like this. If Forge is seen as "the way of writing code" maybe something should be created to get homogenized code. PMD, Checkstyle, human review and so one..... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1275) @PUT method shouldn't have a @Path

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1275?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1275: -------------------------------------- Fix Version/s: 2.x Future > @PUT method shouldn't have a @Path > ---------------------------------- > > Key: FORGE-1275 > URL: https://issues.jboss.org/browse/FORGE-1275 > Project: Forge > Issue Type: Bug > Components: Scaffold > Affects Versions: 1.4.2.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > Hi, > In the REST scaffolding, the generate {{update}} method looks like this : > {code} > @PUT > @Path("/{id:[0-9][0-9]*}") > @Consumes("application/xml") > public Response update(Book entity) { > em.merge(entity); > return Response.noContent().build(); > } > {code} > The method has a {{@Path}} annotation with an id and therefore cannot be invoked (without the id that is not used in the method). So it should simply be : > {code} > @PUT > @Consumes("application/xml") > public Response update(Book entity) { > em.merge(entity); > return Response.noContent().build(); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1280) Reads and writes to Configuration do not ensure consistency

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1280?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1280: -------------------------------------- Fix Version/s: 2.x Future > Reads and writes to Configuration do not ensure consistency > ----------------------------------------------------------- > > Key: FORGE-1280 > URL: https://issues.jboss.org/browse/FORGE-1280 > Project: Forge > Issue Type: Bug > Affects Versions: 1.4.1.Final > Reporter: Vineet Reynolds > Fix For: 2.x Future > > > Stale property values are read from the Configuration instance if a property is written to and read from in rapid succession possibly in different threads. > The XMLConfiguration delegate used is thread-safe only as long as multiple threads read from it. And going by the javadocs, manual synchronization is necessary on this instance when a thread writes to it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1271) Adding code conventions to generated code

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1271?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1271: -------------------------------------- Affects Version/s: (was: 2.x Future) > Adding code conventions to generated code > ----------------------------------------- > > Key: FORGE-1271 > URL: https://issues.jboss.org/browse/FORGE-1271 > Project: Forge > Issue Type: Feature Request > Components: Resources API, Scaffold > Reporter: Antonio Goncalves > > Discussion on : https://community.jboss.org/message/842429 > Developers look at Forge as the "way to write Java EE code" or if you like "if those guys write code like this, then we should". > I am digging into some details of the generated code (I am writing a blog about several architectural styles starting with Forge) and I feel coding convention should be homogenized. I know extensions are written by different individuals, but some basic coding conventions should be applied. For example, when you generate a web app with REST and Faces scaffolding, you get some difference : > * Faces Backing Bean use query builder (e.g {{getAll}} method is {{entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();}} and > * REST Endpoint use dynamic queries (the {{listAll}} method is {{"SELECT DISTINCT b FROM Book b ORDER BY b.id"))}} > Method names are different and do the same : > * JSF : {{getAll}} > * REST : {{listAll}} > Attributes > * {{private EntityManager em;}} > * {{private EntityManager entityManager;}} // em would be better > Or the use of {{this}} keyword (JSF beans use {{this.entityManager}} instead of directly {{em}} in REST) > And there are several examples like this. If Forge is seen as "the way of writing code" maybe something should be created to get homogenized code. PMD, Checkstyle, human review and so one..... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1274) Move/Encapsulate Aesh as implementation detail until its APIs better support Proxying

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1274?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1274: -------------------------------------- Fix Version/s: 2.x Future > Move/Encapsulate Aesh as implementation detail until its APIs better support Proxying > ------------------------------------------------------------------------------------- > > Key: FORGE-1274 > URL: https://issues.jboss.org/browse/FORGE-1274 > Project: Forge > Issue Type: Feature Request > Components: UI - Eclipse, UI - Shell > Affects Versions: 2.0.0.Alpha13 > Reporter: Lincoln Baxter III > Fix For: 2.x Future > > > Because the Aesh APIs do not support proxying particularly well, we need to encapsulate them to prevent Proxy errors from causing failures in external consumers of the Shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1271) Adding code conventions to generated code

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1271?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1271: -------------------------------------- Fix Version/s: 2.x Future > Adding code conventions to generated code > ----------------------------------------- > > Key: FORGE-1271 > URL: https://issues.jboss.org/browse/FORGE-1271 > Project: Forge > Issue Type: Feature Request > Components: Resources API, Scaffold > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > Discussion on : https://community.jboss.org/message/842429 > Developers look at Forge as the "way to write Java EE code" or if you like "if those guys write code like this, then we should". > I am digging into some details of the generated code (I am writing a blog about several architectural styles starting with Forge) and I feel coding convention should be homogenized. I know extensions are written by different individuals, but some basic coding conventions should be applied. For example, when you generate a web app with REST and Faces scaffolding, you get some difference : > * Faces Backing Bean use query builder (e.g {{getAll}} method is {{entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();}} and > * REST Endpoint use dynamic queries (the {{listAll}} method is {{"SELECT DISTINCT b FROM Book b ORDER BY b.id"))}} > Method names are different and do the same : > * JSF : {{getAll}} > * REST : {{listAll}} > Attributes > * {{private EntityManager em;}} > * {{private EntityManager entityManager;}} // em would be better > Or the use of {{this}} keyword (JSF beans use {{this.entityManager}} instead of directly {{em}} in REST) > And there are several examples like this. If Forge is seen as "the way of writing code" maybe something should be created to get homogenized code. PMD, Checkstyle, human review and so one..... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1296) Allow constraints to be specified on the versions of the Facets during setup

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1296?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1296: -------------------------------------- Fix Version/s: 2.x Future > Allow constraints to be specified on the versions of the Facets during setup > ---------------------------------------------------------------------------- > > Key: FORGE-1296 > URL: https://issues.jboss.org/browse/FORGE-1296 > Project: Forge > Issue Type: Feature Request > Components: UI - API > Affects Versions: 2.0.0.Alpha14 > Reporter: Vineet Reynolds > Assignee: George Gastaldi > Fix For: 2.x Future > > > The current implementation of the Scaffold and possibly other addons, verifies if facets are setup and then proceeds to add the wizards for these facets to the NavigationResult. > It is possible that some of the versions displayed in the individual wizards will not be applicable when used in a composite wizard like the scaffold. We need to find a way for the composite to hint or specify the allowed versions of the individual facets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1266) Implement IgnoreEOF in Forge 2 Shell

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1266?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1266: -------------------------------------- Fix Version/s: 2.x Future > Implement IgnoreEOF in Forge 2 Shell > ------------------------------------ > > Key: FORGE-1266 > URL: https://issues.jboss.org/browse/FORGE-1266 > Project: Forge > Issue Type: Feature Request > Components: UI - Shell > Affects Versions: 2.0.0.Alpha13 > Reporter: Lincoln Baxter III > Fix For: 2.x Future > > > See current IGNOREEOF behavior in Forge 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1299) list-command missing

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1299?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1299: -------------------------------------- Fix Version/s: 2.x Future > list-command missing > -------------------- > > Key: FORGE-1299 > URL: https://issues.jboss.org/browse/FORGE-1299 > Project: Forge > Issue Type: Feature Request > Components: UI - Shell > Affects Versions: 2.0.0.Alpha14 > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > {{list-command}} and {{list-command --all}} are missing in the CLI. That is quite an important one to have an idea of the commands. > But following the issue [FORGE-944] it should be {{command-list}} instead of {{list-command}} (component-verb) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (FORGE-1028) Add support in the Java Parser to resolve JDT bindings

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1028?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated FORGE-1028: -------------------------------------- Fix Version/s: 2.x Future > Add support in the Java Parser to resolve JDT bindings > ------------------------------------------------------ > > Key: FORGE-1028 > URL: https://issues.jboss.org/browse/FORGE-1028 > Project: Forge > Issue Type: Feature Request > Components: Parsers / File Manipulation > Reporter: Vineet Reynolds > Fix For: 2.x Future > > > Eclipse JDT allows bindings to be resolved from an AST tree, provided that the compilation units are accessible. This allows for the bindings to be inspected at runtime. See the [setResolveBindings method|http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt....] in the Eclipse ASTParser API. > We do not provide the ASTParser with an {{IProject}} nor do we configure the {{Environment}}, thus resulting in an inability to resolve the bindings. This should preferably be done with the sources of the project dependencies and the project sources, so that we can retrieve the type information in the JavaParser. This may also help in resolving FORGE-773, although it still requires the sources to be available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues November 2013