May 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2081) Being able to add a new CDI event producer to an existing class

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/FORGE-2081?page=com.atlassian.jira.plugin... ] Antonio Goncalves updated FORGE-2081: ------------------------------------- Description: It would be useful to have a command to add a new CDI event producer to an existing class. A command such as : {code} cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder {code} Would add to an existing class the following code : {code} @Inject private Event<PurchaseOrder> eventPurchaseOrder; public void firePurchaseOrder() { PurchaseOrder purchaseOrder = new PurchaseOrder(); event.fire(order); } {code} Adding qualifiers : {code} cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder --qualifiers MyQualif MySecondQualif {code} {code} @Inject @MyQualif @MySecondQualif private Event<PurchaseOrder> eventPurchaseOrder; public void firePurchaseOrder() { PurchaseOrder purchaseOrder = new PurchaseOrder(); event.fire(order); } {code} was: It would be useful to have a command to add a new CDI event producer to an existing class. A command such as : {code} cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder {code} Would add to an existing class the following code : {code} @Inject private Event<PurchaseOrder> eventPurchaseOrder; public void firePurchaseOrder() { PurchaseOrder purchaseOrder = new PurchaseOrder(); event.fire(order); } {code} > Being able to add a new CDI event producer to an existing class > --------------------------------------------------------------- > > Key: FORGE-2081 > URL: https://issues.jboss.org/browse/FORGE-2081 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.12.1.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > It would be useful to have a command to add a new CDI event producer to an existing class. A command such as : > {code} > cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder > {code} > Would add to an existing class the following code : > {code} > @Inject > private Event<PurchaseOrder> eventPurchaseOrder; > public void firePurchaseOrder() > { > PurchaseOrder purchaseOrder = new PurchaseOrder(); > event.fire(order); > } > {code} > Adding qualifiers : > {code} > cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder --qualifiers MyQualif MySecondQualif > {code} > {code} > @Inject @MyQualif @MySecondQualif > private Event<PurchaseOrder> eventPurchaseOrder; > public void firePurchaseOrder() > { > PurchaseOrder purchaseOrder = new PurchaseOrder(); > event.fire(order); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2081) Being able to add a new CDI event producer to an existing class

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2081?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2081: ---------------------------------------- You can add an {{Event<String>}} injection by running the following command: {code:java} cdi-add-injection-point --named event --type "javax.enterprise.event.Event<String>" {code} > Being able to add a new CDI event producer to an existing class > --------------------------------------------------------------- > > Key: FORGE-2081 > URL: https://issues.jboss.org/browse/FORGE-2081 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.12.1.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > It would be useful to have a command to add a new CDI event producer to an existing class. A command such as : > {code} > cdi-add-event-producer --named firePurchaseOrder --type PurchaseOrder > {code} > Would add to an existing class the following code : > {code} > @Inject > private Event<PurchaseOrder> eventPurchaseOrder; > public void firePurchaseOrder() > { > PurchaseOrder purchaseOrder = new PurchaseOrder(); > event.fire(order); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2082) Being able to add a new CDI event observer to an existing class

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2082?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2082. ---------------------------------- Assignee: George Gastaldi Fix Version/s: 2.16.1.Final (was: 2.x Future) Resolution: Done > Being able to add a new CDI event observer to an existing class > --------------------------------------------------------------- > > Key: FORGE-2082 > URL: https://issues.jboss.org/browse/FORGE-2082 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.12.1.Final > Reporter: Antonio Goncalves > Assignee: George Gastaldi > Fix For: 2.16.1.Final > > > It would be useful to have a command to add a new CDI event observer to an existing class. A command such as : > {code} > cdi-add-event-observer --named observePurchaseOrder --type PurchaseOrder > {code} > Would add to an existing class the following code : > {code} > public void observePurchaseOrder(@Observes PurchaseOrder purchaseOrder) > { > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2332) ClassLoaderFacet.getClassLoader() does not work for Web projects

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2332: -------------------------------------- Summary: ClassLoaderFacet.getClassLoader() does not work for Web projects Key: FORGE-2332 URL: https://issues.jboss.org/browse/FORGE-2332 Project: Forge Issue Type: Bug Components: Projects Affects Versions: 2.16.0.Final Reporter: George Gastaldi Fix For: 2.x Future WAR files must be handled accordingly -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2331) Refactor New and Add commands

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-2331: ---------------------------------------- Summary: 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.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2328) Move the Setup commands under a setup package or leave them under ui ?

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2328?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2328: ---------------------------------------- Yes, deprecating it is a good idea. > Move the Setup commands under a setup package or leave them under ui ? > ---------------------------------------------------------------------- > > Key: FORGE-2328 > URL: https://issues.jboss.org/browse/FORGE-2328 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.16.0.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > In the Java EE addon, all the commands are under a {{ui}} package (eg. {{javaee.cdi.ui}}, {{javaee.ejb.ui}}). > The problem is that some {{setup}} commands are under the sub-package {{setup}} (eg. {{javaee.jpa.ui.setup.JPASetupWizard}}, {{javaee.jaxws.ui.setup.JAXWSSetupWizard}}) and others aren't ({{javaee.faces.ui.FacesSetupWizard}}). > It would be nice to opt for one (under {{setup}}) or the other (under {{ui}}) and make them all the same. The pb is that some APIs might be broken. The best choice (less breaking APIs) is to move them under {{ui}} : only JPA has an API under {{setup}}, some commands only have the impl under {{setup}} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2328) Move the Setup commands under a setup package or leave them under ui ?

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/FORGE-2328?page=com.atlassian.jira.plugin... ] Antonio Goncalves commented on FORGE-2328: ------------------------------------------ I'm just concerned with {{org.jboss.forge.addon.javaee.jpa.ui.setup.JPASetupWizard}} which is in the API module (and therefore could break compatibility when moved down to {{ui}}). Or we can deprecate it and create a new one > Move the Setup commands under a setup package or leave them under ui ? > ---------------------------------------------------------------------- > > Key: FORGE-2328 > URL: https://issues.jboss.org/browse/FORGE-2328 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.16.0.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > In the Java EE addon, all the commands are under a {{ui}} package (eg. {{javaee.cdi.ui}}, {{javaee.ejb.ui}}). > The problem is that some {{setup}} commands are under the sub-package {{setup}} (eg. {{javaee.jpa.ui.setup.JPASetupWizard}}, {{javaee.jaxws.ui.setup.JAXWSSetupWizard}}) and others aren't ({{javaee.faces.ui.FacesSetupWizard}}). > It would be nice to opt for one (under {{setup}}) or the other (under {{ui}}) and make them all the same. The pb is that some APIs might be broken. The best choice (less breaking APIs) is to move them under {{ui}} : only JPA has an API under {{setup}}, some commands only have the impl under {{setup}} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2328) Move the Setup commands under a setup package or leave them under ui ?

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2328?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2328: ---------------------------------------- +1 to move them to ui package. I don't remember why I created the setup sub-package, but that doesn't really matter since this is just an implementation detail. > Move the Setup commands under a setup package or leave them under ui ? > ---------------------------------------------------------------------- > > Key: FORGE-2328 > URL: https://issues.jboss.org/browse/FORGE-2328 > Project: Forge > Issue Type: Sub-task > Components: Java EE > Affects Versions: 2.16.0.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > In the Java EE addon, all the commands are under a {{ui}} package (eg. {{javaee.cdi.ui}}, {{javaee.ejb.ui}}). > The problem is that some {{setup}} commands are under the sub-package {{setup}} (eg. {{javaee.jpa.ui.setup.JPASetupWizard}}, {{javaee.jaxws.ui.setup.JAXWSSetupWizard}}) and others aren't ({{javaee.faces.ui.FacesSetupWizard}}). > It would be nice to opt for one (under {{setup}}) or the other (under {{ui}}) and make them all the same. The pb is that some APIs might be broken. The best choice (less breaking APIs) is to move them under {{ui}} : only JPA has an API under {{setup}}, some commands only have the impl under {{setup}} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2329) Adding JSon-P support

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-2329: ---------------------------------------- Summary: Adding JSon-P support Key: FORGE-2329 URL: https://issues.jboss.org/browse/FORGE-2329 Project: Forge Issue Type: Sub-task Components: Java EE Affects Versions: 2.16.0.Final Reporter: Antonio Goncalves Fix For: 2.x Future It would be good to have support for JSon-P in Java EE addons. This way we could easily setup the JSon-P dependencies (with a {{jsonp-setup}} command). The JSon-P facet needs to check if the JavaEE7Facet is installed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2330) Adding JSon-B support

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-2330: ---------------------------------------- Summary: Adding JSon-B support Key: FORGE-2330 URL: https://issues.jboss.org/browse/FORGE-2330 Project: Forge Issue Type: Sub-task Components: Java EE Affects Versions: 2.16.0.Final Reporter: Antonio Goncalves Fix For: 2.x Future It would be good to have support for JSon-B in Java EE addons. This way we could easily setup the JSon-B dependencies (with a {{jsonb-setup}} command). The JSon-B facet needs to check if the JavaEE8Facet is installed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues May 2015