September 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2464) Cannot use '~' in the type parameter of a jpa-new-field

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2464?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2464. ---------------------------------- Fix Version/s: 2.19.1.Final (was: 2.x Future) Assignee: George Gastaldi Resolution: Done > Cannot use '~' in the type parameter of a jpa-new-field > -------------------------------------------------------- > > Key: FORGE-2464 > URL: https://issues.jboss.org/browse/FORGE-2464 > Project: Forge > Issue Type: Bug > Components: Java EE > Affects Versions: 2.19.0.Final > Reporter: Antonio Goncalves > Assignee: George Gastaldi > Fix For: 2.19.1.Final > > > In the following script I can create an enum in the package {{~.model}} using the '~' symbol, but in the {{jpa-new-field}} I can't. It throws an exception : > {code} > java-new-enum --named UserRole --targetPackage ~.model ; > java-new-enum-const USER ; > java-new-enum-const ADMIN ; > jpa-new-entity --named User ; > jpa-new-field --named UserRole --type ~.model.UserRole ; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2477) Upgrade Hibernate Tools to 4.3.1.Final

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2477?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2477. ---------------------------------- Resolution: Done > Upgrade Hibernate Tools to 4.3.1.Final > -------------------------------------- > > Key: FORGE-2477 > URL: https://issues.jboss.org/browse/FORGE-2477 > Project: Forge > Issue Type: Component Upgrade > Components: Database Tools > Affects Versions: 2.19.0.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.19.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2477) Upgrade Hibernate Tools to 4.3.1.Final

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2477: -------------------------------------- Summary: Upgrade Hibernate Tools to 4.3.1.Final Key: FORGE-2477 URL: https://issues.jboss.org/browse/FORGE-2477 Project: Forge Issue Type: Component Upgrade Components: Database Tools Affects Versions: 2.19.0.Final Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 2.19.1.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-51) Add interface or abstract class should implement inherited methods

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-51?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-51. ---------------------------------- Resolution: Done Ok, fixed the naming parameters issue. > Add interface or abstract class should implement inherited methods > ------------------------------------------------------------------ > > Key: ROASTER-51 > URL: https://issues.jboss.org/browse/ROASTER-51 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Priority: Minor > Fix For: 2.15.1.Final > > > When you use addInterface or setExtends, Roaster should bring back automatically (or via a method explicitly call) all inherited method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-51) Add interface or abstract class should implement inherited methods

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/ROASTER-51?page=com.atlassian.jira.plugin... ] Antonio Goncalves commented on ROASTER-51: ------------------------------------------ For the Typed interface, I think we could leave it like that for now. Then, we will have to solve [ROASTER-4] first. > Add interface or abstract class should implement inherited methods > ------------------------------------------------------------------ > > Key: ROASTER-51 > URL: https://issues.jboss.org/browse/ROASTER-51 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Priority: Minor > Fix For: 2.15.1.Final > > > When you use addInterface or setExtends, Roaster should bring back automatically (or via a method explicitly call) all inherited method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-51) Add interface or abstract class should implement inherited methods

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-51?page=com.atlassian.jira.plugin... ] George Gastaldi commented on ROASTER-51: ---------------------------------------- The Naming Parameters issue is easy to solve. As for the Duplicate method issue, the solution is to call addInterface after the method is added (You could call {{Refactory.importAbstractMethods}} directly too). This will prevent from having duplicate methods The Typed interface looks like the hardest issue to solve, as it may involve some API changes, but I´m open to suggestions for how to solve this > Add interface or abstract class should implement inherited methods > ------------------------------------------------------------------ > > Key: ROASTER-51 > URL: https://issues.jboss.org/browse/ROASTER-51 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Priority: Minor > Fix For: 2.15.1.Final > > > When you use addInterface or setExtends, Roaster should bring back automatically (or via a method explicitly call) all inherited method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-51) Add interface or abstract class should implement inherited methods

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-51?page=com.atlassian.jira.plugin... ] George Gastaldi reopened ROASTER-51: ------------------------------------ > Add interface or abstract class should implement inherited methods > ------------------------------------------------------------------ > > Key: ROASTER-51 > URL: https://issues.jboss.org/browse/ROASTER-51 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Priority: Minor > Fix For: 2.15.1.Final > > > When you use addInterface or setExtends, Roaster should bring back automatically (or via a method explicitly call) all inherited method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-51) Add interface or abstract class should implement inherited methods

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/ROASTER-51?page=com.atlassian.jira.plugin... ] Antonio Goncalves commented on ROASTER-51: ------------------------------------------ [~gastaldi]] There are a few issues with this. h3. Typed interface A {{ConstraintValidator}} needs to be typed, such as : {code} public class MaxValidatorForString implements ConstraintValidator<Max, Number> { @Override public void initialize(Max constraint) { } @Override public boolean isValid(Number value, ConstraintValidatorContext context) { return false; } } {code} For this to work, at the moment we use the following syntax, plus, we create the methods to implement: {code} javaClass.addInterface("ConstraintValidator<" + constraintAnnotation + ", " + dataType + ">"); {code} Unfortunatelly we cannot override such syntax h3. Naming parameters When we override an interface, the method parameters are named arg0, arg1.... such as : {code} javaClassSource.setPackage("org.agoncal.myproj").setName("MyJSFConverter2").addInterface(Converter.class, true); public class MyJSFConverter2 implements Converter { @Override public Object getAsObject(FacesContext arg0, UIComponent arg1, String arg2) { return null; } @Override public String getAsString(FacesContext arg0, UIComponent arg1, Object arg2) { return null; } } {code} Why not naming parameters with lowercase(className) and maybe something different for datatypes (s1, s2... for strings). And when there is only one of the same type, forget the numbering : {code} @Override public Object getAsObject(FacesContext facesContext, UIComponent uiComponent, String s) { return null; } @Override public String getAsString(FacesContext facesContext, UIComponent uiComponent, Object object) { return null; } {code} h3. Duplicate method If you orverride an interface, and then create the exact same method signature, the method is duplicated and it doesn't compile (I suppose there is not much we can do) {code} javaClassSource.setPackage("org.agoncal.myproj").setName("MyJSFConverter2").addInterface(Converter.class, true) .addAnnotation(FacesConverter.class); // Methods MethodSource<?> getAsObject = javaClassSource.addMethod().setPublic().setName("getAsObject") .setReturnType(Object.class); getAsObject.addParameter(FacesContext.class, "context").setFinal(true); getAsObject.addParameter(UIComponent.class, "component").setFinal(true); getAsObject.addParameter(String.class, "value").setFinal(true); getAsObject.setBody("throw new UnsupportedOperationException(\"not yet implemented\");") .addAnnotation(Override.class); MethodSource<?> getAsString = javaClassSource.addMethod().setPublic().setName("getAsString") .setReturnType(String.class); getAsString.addParameter(FacesContext.class, "context").setFinal(true); getAsString.addParameter(UIComponent.class, "component").setFinal(true); getAsString.addParameter(Object.class, "value").setFinal(true); getAsString.setBody("return value.toString();") .addAnnotation(Override.class); {code} > Add interface or abstract class should implement inherited methods > ------------------------------------------------------------------ > > Key: ROASTER-51 > URL: https://issues.jboss.org/browse/ROASTER-51 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Priority: Minor > Fix For: 2.15.1.Final > > > When you use addInterface or setExtends, Roaster should bring back automatically (or via a method explicitly call) all inherited method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-81) Introduce utility classes to allow creation of design patterns

by Anonymous (JIRA)

[ https://issues.jboss.org/browse/ROASTER-81?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when George Gastaldi created pull request #42 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Introduce utility classes to allow creation of design patterns > --------------------------------------------------------------- > > Key: ROASTER-81 > URL: https://issues.jboss.org/browse/ROASTER-81 > Project: Roaster > Issue Type: Feature Request > Components: API > Affects Versions: 2.15.0.Final > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.x Future > > > https://github.com/gastaldi/design-patterns/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

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

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/FORGE-1271?page=com.atlassian.jira.plugin... ] Antonio Goncalves updated FORGE-1271: ------------------------------------- Fix Version/s: (was: 2.x Future) > Adding code conventions to scaffolded code > ------------------------------------------ > > Key: FORGE-1271 > URL: https://issues.jboss.org/browse/FORGE-1271 > Project: Forge > Issue Type: Sub-task > Components: Resources, Scaffold > Affects Versions: 2.0.0.Alpha14 > Reporter: Antonio Goncalves > Fix For: 3.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 was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues September 2015