[JBoss JIRA] (FORGE-2331) Refactor New and Add commands
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin... ]
George Gastaldi edited comment on FORGE-2331 at 9/4/15 1:46 PM:
----------------------------------------------------------------
The above solution would only work with a @Typed(TargetPackage.class), because there would be ambiguous dependency resolution issues (conflicting with @Inject UIInput<String>)
was (Author: gastaldi):
The above solution wouldn't work, because there would be ambiguous dependency resolution issues (conflicting with @Inject UIInput<String>)
> Refactor New and Add commands
> -----------------------------
>
> Key: FORGE-2331
> URL: https://issues.jboss.org/browse/FORGE-2331
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.16.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> {code}
> agoncal gastaldi Do you have a moment ?
> gastaldi agoncal, sure, what's up?
> agoncal gastaldi I'm getting more confident with Forge and I can create more and more commands....
> agoncal but actually, it's xxxNewxxxCommands
> agoncal In Forge I see commands to create new classes (artifacts) : CDINewBean, JPANewEntity....
> agoncal And commands to add code to existing classes : JPAAddField, CDIAddInjectionPoint
> agoncal I find xxxAddCommands more difficult to write than xxxNewCommands
> agoncal For example :
> agoncal ServletNewServletCommand extends from AbstractServletNewCommand which extends from AbstractJavaSourceCommand
> agoncal AbstractJavaSourceCommand gives me targetPackage, named and overwrite
> agoncal I would like to have the same kind of hierarchy to easy my xxxAddCommands development
> agoncal Something like :
> agoncal ServletAddContextCommand extends from AbstractServletAddCommand which extends from AbstractAddCommand
> agoncal And AbstractAddCommand would give me targetClass, named and overwrite
> agoncal gastaldi WDYT ?
> gastaldi hmmm
> gastaldi interesting
> gastaldi do all xxxAddCommands have targetClass, named and overwrite?
> agoncal gastaldi Yes. You usually want to add something that is named (attribute, method...) into a class (target class) and if it's already there you want to override it
> gastaldi hmmm
> gastaldi I don't see it as a rule for the Add commands
> gastaldi for example, AddDependenciesCommand does not feature that
> agoncal Well, the New commands are : targetPackage, named and overwrite and I think it represents most of the cases
> agoncal gastaldi are you talking about project-add-dependencies ?
> gastaldi yes
> agoncal I'm more focused on Java EE code (project-add-dependencies is indeed different)
> gastaldi hmm, maybe we don't need to inherit, but have encapsulate these properties
> agoncal yes, why not, I'm trying to get as closed to the current model as possible (so it doesn't break anything)
> agoncal I would like to be as confident to write a AddCommand than a NewCommand, and at the moment it's not the case
> agoncal If there was an AbstractNewCommand and an AbstractAddCommand in just the JavaEE addon, it would make development easier
> agoncal (most of the Java EE commands share the same common properties and behaviour)
> gastaldi ok, but what about the abstract classes per technology ?
> gastaldi are they becoming xxxNewCommands?
> agoncal Well, we could have AbstractNewCommand with targetPackage, named and overwrite, and AbstractCDINewCommands for the prerequisite (CDI needs CDISetup)
> agoncal And same for the add :
> agoncal AbstractAddCommand with targetClass, named and overwrite, and AbstractCDIAddCommands
> agoncal .... humm....
> agoncal Both AbstractCDINewCommands and AbstractCDIAddCommands are used for the prerequisite...
> gastaldi it's awesome that you found a pattern between these command types
> gastaldi but I think that at some point inheritance won't be the answer :)
> agoncal gastaldi Thanks to writing the documentation ;o)
> agoncal gastaldi Totally agree !
> gastaldi what documentation?
> agoncal I feel a bit stuck with inheritance sometimes
> agoncal Because Add and New both have a named
> gastaldi agoncal, yes, perhaps we need to start looking at encapsulation instead
> agoncal Add has a targetClass and New a targetPackage
> gastaldi that is a more flexible approach
> agoncal Yes !
> agoncal But that might break some current APIs
> agoncal (don't know)
> gastaldi we could have a class with these common attributes and pass them to the UIBuildder
> gastaldi *UIBuilder
> agoncal Yes
> agoncal As a developper, I really just want to focus on writing the "business logic" of a command and less boiler plate code
> gastaldi that's right
> gastaldi totally agree
> agoncal When writing a Add command I'm happy that the targetPackage is being taking care of
> agoncal I also want the same for Add
> agoncal (which is not the case at the moment)
> gastaldi hmmm
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2471) AngularJS scaffolded app doesn't load data from sakila db
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/FORGE-2471?page=com.atlassian.jira.plugin... ]
Koen Aers moved JBIDE-18549 to FORGE-2471:
------------------------------------------
Project: Forge (was: Tools (JBoss Tools))
Key: FORGE-2471 (was: JBIDE-18549)
Workflow: GIT Pull Request workflow with automatic PR triggers (was: GIT Pull Request workflow )
Component/s: Scaffold
(was: forge)
Affects Version/s: 2.17.0.Final
(was: 4.2.0.CR2)
Fix Version/s: (was: 4.3.0.CR1)
> AngularJS scaffolded app doesn't load data from sakila db
> ---------------------------------------------------------
>
> Key: FORGE-2471
> URL: https://issues.jboss.org/browse/FORGE-2471
> Project: Forge
> Issue Type: Bug
> Components: Scaffold
> Affects Versions: 2.17.0.Final
> Reporter: Pavol Srna
> Assignee: Vineet Reynolds
> Priority: Critical
> Attachments: angular.png, faces.png, server.log
>
>
> HTML5 scaffolded app cannot load data from database:
> Scaffolding JSF on the same data model works. see screenshots.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2331) Refactor New and Add commands
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on FORGE-2331:
----------------------------------------
The above solution wouldn't work, because there would be ambiguous dependency resolution issues (conflicting with @Inject UIInput<String>)
> Refactor New and Add commands
> -----------------------------
>
> Key: FORGE-2331
> URL: https://issues.jboss.org/browse/FORGE-2331
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.16.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> {code}
> agoncal gastaldi Do you have a moment ?
> gastaldi agoncal, sure, what's up?
> agoncal gastaldi I'm getting more confident with Forge and I can create more and more commands....
> agoncal but actually, it's xxxNewxxxCommands
> agoncal In Forge I see commands to create new classes (artifacts) : CDINewBean, JPANewEntity....
> agoncal And commands to add code to existing classes : JPAAddField, CDIAddInjectionPoint
> agoncal I find xxxAddCommands more difficult to write than xxxNewCommands
> agoncal For example :
> agoncal ServletNewServletCommand extends from AbstractServletNewCommand which extends from AbstractJavaSourceCommand
> agoncal AbstractJavaSourceCommand gives me targetPackage, named and overwrite
> agoncal I would like to have the same kind of hierarchy to easy my xxxAddCommands development
> agoncal Something like :
> agoncal ServletAddContextCommand extends from AbstractServletAddCommand which extends from AbstractAddCommand
> agoncal And AbstractAddCommand would give me targetClass, named and overwrite
> agoncal gastaldi WDYT ?
> gastaldi hmmm
> gastaldi interesting
> gastaldi do all xxxAddCommands have targetClass, named and overwrite?
> agoncal gastaldi Yes. You usually want to add something that is named (attribute, method...) into a class (target class) and if it's already there you want to override it
> gastaldi hmmm
> gastaldi I don't see it as a rule for the Add commands
> gastaldi for example, AddDependenciesCommand does not feature that
> agoncal Well, the New commands are : targetPackage, named and overwrite and I think it represents most of the cases
> agoncal gastaldi are you talking about project-add-dependencies ?
> gastaldi yes
> agoncal I'm more focused on Java EE code (project-add-dependencies is indeed different)
> gastaldi hmm, maybe we don't need to inherit, but have encapsulate these properties
> agoncal yes, why not, I'm trying to get as closed to the current model as possible (so it doesn't break anything)
> agoncal I would like to be as confident to write a AddCommand than a NewCommand, and at the moment it's not the case
> agoncal If there was an AbstractNewCommand and an AbstractAddCommand in just the JavaEE addon, it would make development easier
> agoncal (most of the Java EE commands share the same common properties and behaviour)
> gastaldi ok, but what about the abstract classes per technology ?
> gastaldi are they becoming xxxNewCommands?
> agoncal Well, we could have AbstractNewCommand with targetPackage, named and overwrite, and AbstractCDINewCommands for the prerequisite (CDI needs CDISetup)
> agoncal And same for the add :
> agoncal AbstractAddCommand with targetClass, named and overwrite, and AbstractCDIAddCommands
> agoncal .... humm....
> agoncal Both AbstractCDINewCommands and AbstractCDIAddCommands are used for the prerequisite...
> gastaldi it's awesome that you found a pattern between these command types
> gastaldi but I think that at some point inheritance won't be the answer :)
> agoncal gastaldi Thanks to writing the documentation ;o)
> agoncal gastaldi Totally agree !
> gastaldi what documentation?
> agoncal I feel a bit stuck with inheritance sometimes
> agoncal Because Add and New both have a named
> gastaldi agoncal, yes, perhaps we need to start looking at encapsulation instead
> agoncal Add has a targetClass and New a targetPackage
> gastaldi that is a more flexible approach
> agoncal Yes !
> agoncal But that might break some current APIs
> agoncal (don't know)
> gastaldi we could have a class with these common attributes and pass them to the UIBuildder
> gastaldi *UIBuilder
> agoncal Yes
> agoncal As a developper, I really just want to focus on writing the "business logic" of a command and less boiler plate code
> gastaldi that's right
> gastaldi totally agree
> agoncal When writing a Add command I'm happy that the targetPackage is being taking care of
> agoncal I also want the same for Add
> agoncal (which is not the case at the moment)
> gastaldi hmmm
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2470) List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy (by mid-November 2015)
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2470?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2470:
-------------------------------------
Summary: List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy (by mid-November 2015) (was: List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy)
> List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy (by mid-November 2015)
> ------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2470
> URL: https://issues.jboss.org/browse/FORGE-2470
> Project: Forge
> Issue Type: Task
> Components: Brainstorming
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
> * [ROASTER-51] - Add interface or abstract class should implement inherited methods
> * [FORGE-1808] - Being able to have inheritance in CDI
> * [FORGE-1478] - Being able to have inheritance in JPA
> * [FORGE-1594] - Being able to create a new JSF View
> * [FORGE-2081] - Being able to add a new CDI event producer to an existing class
> * [FORGE-2079] - Being able to add a new CDI producer field
> * [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
> * [FORGE-2225] - Being able to add a new CDI producer method to an existing class
> * [FORGE-2318] - Being able to setup a logger
> * [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
> * [FORGE-2466] - Cannot use '~' in most of the command parameters
> * [FORGE-2468] - Being able to add methods to an existing JSF backing bean
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin... ]
Antonio Goncalves edited comment on FORGE-2469 at 9/4/15 10:15 AM:
-------------------------------------------------------------------
https://gist.github.com/gastaldi/46b3f38bc38c5efcc0ba
agoncal You could apply it to :
agoncal private UIInput<String> targetPackage
agoncal private UIInput<String>
agoncal private UIInput<Boolean> overwrite
agoncal private UISelectOne<JavaResource> targetClass;
was (Author: agoncal):
https://gist.github.com/gastaldi/46b3f38bc38c5efcc0ba
> Getting a design pattern right for add commands
> -----------------------------------------------
>
> Key: FORGE-2469
> URL: https://issues.jboss.org/browse/FORGE-2469
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> The {{new}} commands are straight forward, we just create a new artifact (mostly classes in the Java EE addon). {{add}} commands are meant to add code to existing code. So all the add}} commands have a {{targetClass}} attribute. The {{targetClass}} points to the current class, or can point to a different one.
> The algorithm to get the {{targetClass}} is very different from command to command (see below). It would be very helpfull to find a generic design pattern that could be applicable to most of the {{add}} commands.
> {code:title=JavaEqualsHashcodeCommand}
> @Override
> public void initializeUI(UIBuilder builder) throws Exception
> {
> (...)
> UISelection<Object> initialSelection = uiContext.getInitialSelection();
> if (initialSelection.get() instanceof JavaResource)
> {
> targetClass.setValue((JavaResource) initialSelection.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> @Override
> public Result execute(UIExecutionContext context) throws Exception
> {
> (...)
> if (targetClass.hasMethodSignature("equals", Object.class))
> {
> if (prompt.promptBoolean("Class already has an equals method. Would you like it to be overwritten?"))
> {code}
> {code:title=CDIAddInjectionPointCommand}
> private void setupTargetClasses(UIContext uiContext)
> {
> UISelection<FileResource<?>> selection = uiContext.getInitialSelection();
> Project project = getSelectedProject(uiContext);
> final List<JavaResource> classes = cdiOperations.getProjectInjectionPointBeans(project);
> targetClass.setValueChoices(classes);
> int idx = -1;
> if (!selection.isEmpty())
> {
> idx = classes.indexOf(selection.get());
> }
> if (idx == -1)
> {
> idx = classes.size() - 1;
> }
> if (idx != -1)
> {
> targetClass.setDefaultValue(classes.get(idx));
> }
> }
> {code}
> {code:title=CDIAddObserverMethodCommand}
> private void setupTargetClass(UIContext uiContext, Project project)
> {
> UISelection<Resource<?>> resource = uiContext.getInitialSelection();
> if (resource.get() instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) resource.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> }
> {code}
> {code:title=FacesNewValidatorMethodCommand}
> public void initializeUI(UIBuilder builder) throws Exception
> {
> Object selection = builder.getUIContext().getInitialSelection().get();
> if (selection instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) selection);
> }
> builder.add(targetClass).add(named);
> }
> @Override
> public void validate(UIValidationContext validator)
> {
> try
> {
> JavaClassSource source = targetClass.getValue().reify(JavaResource.class).getJavaType();
> (...)
> }
> catch (FileNotFoundException e)
> {
> validator.addValidationError(targetClass, "Target Java class not found.");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2331) Refactor New and Add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin... ]
Antonio Goncalves commented on FORGE-2331:
------------------------------------------
https://gist.github.com/gastaldi/46b3f38bc38c5efcc0ba
> Refactor New and Add commands
> -----------------------------
>
> Key: FORGE-2331
> URL: https://issues.jboss.org/browse/FORGE-2331
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.16.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> {code}
> agoncal gastaldi Do you have a moment ?
> gastaldi agoncal, sure, what's up?
> agoncal gastaldi I'm getting more confident with Forge and I can create more and more commands....
> agoncal but actually, it's xxxNewxxxCommands
> agoncal In Forge I see commands to create new classes (artifacts) : CDINewBean, JPANewEntity....
> agoncal And commands to add code to existing classes : JPAAddField, CDIAddInjectionPoint
> agoncal I find xxxAddCommands more difficult to write than xxxNewCommands
> agoncal For example :
> agoncal ServletNewServletCommand extends from AbstractServletNewCommand which extends from AbstractJavaSourceCommand
> agoncal AbstractJavaSourceCommand gives me targetPackage, named and overwrite
> agoncal I would like to have the same kind of hierarchy to easy my xxxAddCommands development
> agoncal Something like :
> agoncal ServletAddContextCommand extends from AbstractServletAddCommand which extends from AbstractAddCommand
> agoncal And AbstractAddCommand would give me targetClass, named and overwrite
> agoncal gastaldi WDYT ?
> gastaldi hmmm
> gastaldi interesting
> gastaldi do all xxxAddCommands have targetClass, named and overwrite?
> agoncal gastaldi Yes. You usually want to add something that is named (attribute, method...) into a class (target class) and if it's already there you want to override it
> gastaldi hmmm
> gastaldi I don't see it as a rule for the Add commands
> gastaldi for example, AddDependenciesCommand does not feature that
> agoncal Well, the New commands are : targetPackage, named and overwrite and I think it represents most of the cases
> agoncal gastaldi are you talking about project-add-dependencies ?
> gastaldi yes
> agoncal I'm more focused on Java EE code (project-add-dependencies is indeed different)
> gastaldi hmm, maybe we don't need to inherit, but have encapsulate these properties
> agoncal yes, why not, I'm trying to get as closed to the current model as possible (so it doesn't break anything)
> agoncal I would like to be as confident to write a AddCommand than a NewCommand, and at the moment it's not the case
> agoncal If there was an AbstractNewCommand and an AbstractAddCommand in just the JavaEE addon, it would make development easier
> agoncal (most of the Java EE commands share the same common properties and behaviour)
> gastaldi ok, but what about the abstract classes per technology ?
> gastaldi are they becoming xxxNewCommands?
> agoncal Well, we could have AbstractNewCommand with targetPackage, named and overwrite, and AbstractCDINewCommands for the prerequisite (CDI needs CDISetup)
> agoncal And same for the add :
> agoncal AbstractAddCommand with targetClass, named and overwrite, and AbstractCDIAddCommands
> agoncal .... humm....
> agoncal Both AbstractCDINewCommands and AbstractCDIAddCommands are used for the prerequisite...
> gastaldi it's awesome that you found a pattern between these command types
> gastaldi but I think that at some point inheritance won't be the answer :)
> agoncal gastaldi Thanks to writing the documentation ;o)
> agoncal gastaldi Totally agree !
> gastaldi what documentation?
> agoncal I feel a bit stuck with inheritance sometimes
> agoncal Because Add and New both have a named
> gastaldi agoncal, yes, perhaps we need to start looking at encapsulation instead
> agoncal Add has a targetClass and New a targetPackage
> gastaldi that is a more flexible approach
> agoncal Yes !
> agoncal But that might break some current APIs
> agoncal (don't know)
> gastaldi we could have a class with these common attributes and pass them to the UIBuildder
> gastaldi *UIBuilder
> agoncal Yes
> agoncal As a developper, I really just want to focus on writing the "business logic" of a command and less boiler plate code
> gastaldi that's right
> gastaldi totally agree
> agoncal When writing a Add command I'm happy that the targetPackage is being taking care of
> agoncal I also want the same for Add
> agoncal (which is not the case at the moment)
> gastaldi hmmm
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin... ]
Antonio Goncalves commented on FORGE-2469:
------------------------------------------
https://gist.github.com/gastaldi/46b3f38bc38c5efcc0ba
> Getting a design pattern right for add commands
> -----------------------------------------------
>
> Key: FORGE-2469
> URL: https://issues.jboss.org/browse/FORGE-2469
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> The {{new}} commands are straight forward, we just create a new artifact (mostly classes in the Java EE addon). {{add}} commands are meant to add code to existing code. So all the add}} commands have a {{targetClass}} attribute. The {{targetClass}} points to the current class, or can point to a different one.
> The algorithm to get the {{targetClass}} is very different from command to command (see below). It would be very helpfull to find a generic design pattern that could be applicable to most of the {{add}} commands.
> {code:title=JavaEqualsHashcodeCommand}
> @Override
> public void initializeUI(UIBuilder builder) throws Exception
> {
> (...)
> UISelection<Object> initialSelection = uiContext.getInitialSelection();
> if (initialSelection.get() instanceof JavaResource)
> {
> targetClass.setValue((JavaResource) initialSelection.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> @Override
> public Result execute(UIExecutionContext context) throws Exception
> {
> (...)
> if (targetClass.hasMethodSignature("equals", Object.class))
> {
> if (prompt.promptBoolean("Class already has an equals method. Would you like it to be overwritten?"))
> {code}
> {code:title=CDIAddInjectionPointCommand}
> private void setupTargetClasses(UIContext uiContext)
> {
> UISelection<FileResource<?>> selection = uiContext.getInitialSelection();
> Project project = getSelectedProject(uiContext);
> final List<JavaResource> classes = cdiOperations.getProjectInjectionPointBeans(project);
> targetClass.setValueChoices(classes);
> int idx = -1;
> if (!selection.isEmpty())
> {
> idx = classes.indexOf(selection.get());
> }
> if (idx == -1)
> {
> idx = classes.size() - 1;
> }
> if (idx != -1)
> {
> targetClass.setDefaultValue(classes.get(idx));
> }
> }
> {code}
> {code:title=CDIAddObserverMethodCommand}
> private void setupTargetClass(UIContext uiContext, Project project)
> {
> UISelection<Resource<?>> resource = uiContext.getInitialSelection();
> if (resource.get() instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) resource.get());
> }
> targetClass.setValueChoices(projectOperations.getProjectClasses(project));
> }
> {code}
> {code:title=FacesNewValidatorMethodCommand}
> public void initializeUI(UIBuilder builder) throws Exception
> {
> Object selection = builder.getUIContext().getInitialSelection().get();
> if (selection instanceof JavaResource)
> {
> targetClass.setDefaultValue((JavaResource) selection);
> }
> builder.add(targetClass).add(named);
> }
> @Override
> public void validate(UIValidationContext validator)
> {
> try
> {
> JavaClassSource source = targetClass.getValue().reify(JavaResource.class).getJavaType();
> (...)
> }
> catch (FileNotFoundException e)
> {
> validator.addValidationError(targetClass, "Target Java class not found.");
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-1808) Being able to have inheritance in CDI
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-1808?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-1808:
-------------------------------------
Description:
It would be nice if CDI bean could implement interfaces (see [ROASTER-51]) and extend other beans
{code}
cdi-new-bean --named MyBean --implements MyInterface
cdi-new-bean --named MyBean --extends MyAbstractBean
cdi-new-bean --named MyBean --extends MyAbstractClass --implements MyInterface
{code}
> Being able to have inheritance in CDI
> -------------------------------------
>
> Key: FORGE-1808
> URL: https://issues.jboss.org/browse/FORGE-1808
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.5.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> It would be nice if CDI bean could implement interfaces (see [ROASTER-51]) and extend other beans
> {code}
> cdi-new-bean --named MyBean --implements MyInterface
> cdi-new-bean --named MyBean --extends MyAbstractBean
> cdi-new-bean --named MyBean --extends MyAbstractClass --implements MyInterface
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2470) List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2470?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2470:
-------------------------------------
Description:
Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
* [ROASTER-51] - Add interface or abstract class should implement inherited methods
* [FORGE-1808] - Being able to have inheritance in CDI
* [FORGE-1478] - Being able to have inheritance in JPA
* [FORGE-1594] - Being able to create a new JSF View
* [FORGE-2081] - Being able to add a new CDI event producer to an existing class
* [FORGE-2079] - Being able to add a new CDI producer field
* [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
* [FORGE-2225] - Being able to add a new CDI producer method to an existing class
* [FORGE-2318] - Being able to setup a logger
* [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
* [FORGE-2466] - Cannot use '~' in most of the command parameters
* [FORGE-2468] - Being able to add methods to an existing JSF backing bean
was:
Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
* [ROASTER-51] - Add interface or abstract class should implement inherited methods
* [FORGE-1478] - Being able to have inheritance in JPA
* [FORGE-1594] - Being able to create a new JSF View
* [FORGE-2081] - Being able to add a new CDI event producer to an existing class
* [FORGE-2079] - Being able to add a new CDI producer field
* [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
* [FORGE-2225] - Being able to add a new CDI producer method to an existing class
* [FORGE-2318] - Being able to setup a logger
* [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
* [FORGE-2466] - Cannot use '~' in most of the command parameters
* [FORGE-2468] - Being able to add methods to an existing JSF backing bean
> List of JIRAs Antoine and Antonio would like to get fixed for their Devoxx Univeristy
> -------------------------------------------------------------------------------------
>
> Key: FORGE-2470
> URL: https://issues.jboss.org/browse/FORGE-2470
> Project: Forge
> Issue Type: Task
> Components: Brainstorming
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Fix For: 2.x Future
>
>
> Here are a few JIRAs that would get to be implemented so it makes the talk smoother :
> * [ROASTER-51] - Add interface or abstract class should implement inherited methods
> * [FORGE-1808] - Being able to have inheritance in CDI
> * [FORGE-1478] - Being able to have inheritance in JPA
> * [FORGE-1594] - Being able to create a new JSF View
> * [FORGE-2081] - Being able to add a new CDI event producer to an existing class
> * [FORGE-2079] - Being able to add a new CDI producer field
> * [FORGE-2099] - scaffold-generate command should have a --targetPackage attribute
> * [FORGE-2225] - Being able to add a new CDI producer method to an existing class
> * [FORGE-2318] - Being able to setup a logger
> * [FORGE-2374] - Being able to generate an abstract or final Java class implementing serialiazable or not
> * [FORGE-2466] - Cannot use '~' in most of the command parameters
> * [FORGE-2468] - Being able to add methods to an existing JSF backing bean
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months