January 2016 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2316: ---------------------------------------- About the filtering choices, we could introduce a interface (something like {{supports(Stack)} and make {{PersistenceContainer}} implement it, just a thought, wdyt? > Brainstorming on introducing "Stacks" > ------------------------------------- > > Key: FORGE-2316 > URL: https://issues.jboss.org/browse/FORGE-2316 > Project: Forge > Issue Type: Sub-task > Reporter: Antonio Goncalves > Fix For: 3.x Future > > > At the moment Forge generates code without having a real notion of a technical stack. For example, creating a JPA Entity for a Java EE 6 application could be different from a Java EE 7 application : > * The {{persistence.xml}} version if different (2.0 / 2.1) > * The {{properties}} are different (e.g. schema generation in 2.1) > * The syntax is different ({{List<MyEntity> m = new ArrayList<MyEntity>}} while it could use diamond syntax for a Java EE 7 stack) > The stack could be choosen when the project is created : > * {{project-new --named myproj}} : let's the developper use Forge without any special stack > * {{project-new --named myproj --stack JavaEE7}} : the generated code will follow Java EE 7 > h3. Possible stacks > A stack would bundle certain facets. Therefore we could have as many stacks as needed. As an example, we could have the following stacks : > * Java EE 6 : JPA 2.0, CDI 1.0, JSF 2.0, Bean Validation 1.0, JTA 1.1 > * Java EE 7 : JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 > * Micro Java EE 7 Service: JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 (but with special Microservice configuration) > * Java EE 8 : JPA 2.1, CDI 2.0, JSF 2.3, Bean Validation 1.2, JTA 1.2, Batch 1.0, JCache 1.1, MVC 1.0 > * Spring 3.x > * Spring 4.x > * .... > h3. Differences in having stacks > h4. Filtering commands > When you pick up a Stack, it gives you access or not to certain commands. For example, if you create a project with a Java EE 6 stack, you won't have access to any Batch, MVC... commands > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity > $ mvc-new-controller --named MyController // only available on EE7 > {code} > h4. Setting up command versions > When you pick up a Stack, it filters the commands that have the right version for the right stack. For example, if you create a Java EE 6 stack, you will get JPA 2.0 commands, for a Java EE 7 stack, the JPA 2.1 commands. Also, the {{version}} parameters will be disabled > {code:title=No stack} > $ project-new --named myproj > $ jpa-new-entity --named MyEntity --jpaVersion 2.1 > $ cdi-new-bean --named MyBean --cdiVersion 1.1 > {code} > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.0 > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.1 > $ jpa-new-converter --named MyConvert // JPA Converters are only available in 2.1 > {code} > h4. API to define a Stack > A stack could be defined with a fluent API such as : > {code} > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).excludes(SpringFacet) > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).allowsFeature(WildflySwarm) > stack("MyOwnStacks").includes(JavaEE7Stack).includes(MyFacet).includes(YourFacet) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2316: ---------------------------------------- Thanks for your feedback. I haven't covered all the JavaEE setup commands yet. I may need your help to add a @StackConstraint on them all. I renamed the {{NullStack}} to {{NoStack}}. In {{StackFacet}}, the {{supports}} is needed to make sure that a Stack is enabled for certain ProjectTypes. For example, it doesn't make sense to create a NodeJS project and choose the JavaEE7 stack. The priority is meant for the "None" stack to be displayed up top. We need to better think about filtering choices. I think we can do that using the {{@StackConstraint}} and the {{StackInspector}} class somehow. > Brainstorming on introducing "Stacks" > ------------------------------------- > > Key: FORGE-2316 > URL: https://issues.jboss.org/browse/FORGE-2316 > Project: Forge > Issue Type: Sub-task > Reporter: Antonio Goncalves > Fix For: 3.x Future > > > At the moment Forge generates code without having a real notion of a technical stack. For example, creating a JPA Entity for a Java EE 6 application could be different from a Java EE 7 application : > * The {{persistence.xml}} version if different (2.0 / 2.1) > * The {{properties}} are different (e.g. schema generation in 2.1) > * The syntax is different ({{List<MyEntity> m = new ArrayList<MyEntity>}} while it could use diamond syntax for a Java EE 7 stack) > The stack could be choosen when the project is created : > * {{project-new --named myproj}} : let's the developper use Forge without any special stack > * {{project-new --named myproj --stack JavaEE7}} : the generated code will follow Java EE 7 > h3. Possible stacks > A stack would bundle certain facets. Therefore we could have as many stacks as needed. As an example, we could have the following stacks : > * Java EE 6 : JPA 2.0, CDI 1.0, JSF 2.0, Bean Validation 1.0, JTA 1.1 > * Java EE 7 : JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 > * Micro Java EE 7 Service: JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 (but with special Microservice configuration) > * Java EE 8 : JPA 2.1, CDI 2.0, JSF 2.3, Bean Validation 1.2, JTA 1.2, Batch 1.0, JCache 1.1, MVC 1.0 > * Spring 3.x > * Spring 4.x > * .... > h3. Differences in having stacks > h4. Filtering commands > When you pick up a Stack, it gives you access or not to certain commands. For example, if you create a project with a Java EE 6 stack, you won't have access to any Batch, MVC... commands > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity > $ mvc-new-controller --named MyController // only available on EE7 > {code} > h4. Setting up command versions > When you pick up a Stack, it filters the commands that have the right version for the right stack. For example, if you create a Java EE 6 stack, you will get JPA 2.0 commands, for a Java EE 7 stack, the JPA 2.1 commands. Also, the {{version}} parameters will be disabled > {code:title=No stack} > $ project-new --named myproj > $ jpa-new-entity --named MyEntity --jpaVersion 2.1 > $ cdi-new-bean --named MyBean --cdiVersion 1.1 > {code} > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.0 > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.1 > $ jpa-new-converter --named MyConvert // JPA Converters are only available in 2.1 > {code} > h4. API to define a Stack > A stack could be defined with a fluent API such as : > {code} > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).excludes(SpringFacet) > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).allowsFeature(WildflySwarm) > stack("MyOwnStacks").includes(JavaEE7Stack).includes(MyFacet).includes(YourFacet) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"

by Antonio Goncalves (JIRA)

[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ] Antonio Goncalves commented on FORGE-2316: ------------------------------------------ Not sure about the naming convention, but choices are mostly in uppercase, shouldn't it be JAVA_EE_7, JAVA_EE_6 : {code} [test]$ project-new --named MyProj --stack java-ee-6 java-ee-7 none {code} Talking about naming again, if the default choice is {{none}}, then maybe rename {{org.jboss.forge.addon.projects.stacks.NullStack}} to {{StackNone}} or {{NoneStack}} (or {{NoStack}}) When I start Forge, and press TAB (not even created a project) I get all these commands that shouldn't be appear : {{constraint-setup, ejb-setup, jms-setup}} What about filtering choices ? This can be tricky, but would help users. For example, if you setup a JAVA EE 7 stack, having GlassFish 3 and JBoss EAP 6 doesn't make sense {code} [test]$ jpa-setup --container CUSTOM_JDBC GLASSFISH_3 JBOSS_AS6 JBOSS_EAP6 NON_JTA TOMEE WILDFLY CUSTOM_JTA GLASSFISH_4 JBOSS_AS7 JBOSS_EAP7 SAP_HCP WEBLOGIC_12C {code} In the {{StackFacet}} I really don't get the priority. If it's just for ordering, name is fine. BTW, what is the use case of overriding the {{supports}} method ? > Brainstorming on introducing "Stacks" > ------------------------------------- > > Key: FORGE-2316 > URL: https://issues.jboss.org/browse/FORGE-2316 > Project: Forge > Issue Type: Sub-task > Reporter: Antonio Goncalves > Fix For: 3.x Future > > > At the moment Forge generates code without having a real notion of a technical stack. For example, creating a JPA Entity for a Java EE 6 application could be different from a Java EE 7 application : > * The {{persistence.xml}} version if different (2.0 / 2.1) > * The {{properties}} are different (e.g. schema generation in 2.1) > * The syntax is different ({{List<MyEntity> m = new ArrayList<MyEntity>}} while it could use diamond syntax for a Java EE 7 stack) > The stack could be choosen when the project is created : > * {{project-new --named myproj}} : let's the developper use Forge without any special stack > * {{project-new --named myproj --stack JavaEE7}} : the generated code will follow Java EE 7 > h3. Possible stacks > A stack would bundle certain facets. Therefore we could have as many stacks as needed. As an example, we could have the following stacks : > * Java EE 6 : JPA 2.0, CDI 1.0, JSF 2.0, Bean Validation 1.0, JTA 1.1 > * Java EE 7 : JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 > * Micro Java EE 7 Service: JPA 2.1, CDI 1.1, JSF 2.2, Bean Validation 1.1, JTA 1.2, Batch 1.0 (but with special Microservice configuration) > * Java EE 8 : JPA 2.1, CDI 2.0, JSF 2.3, Bean Validation 1.2, JTA 1.2, Batch 1.0, JCache 1.1, MVC 1.0 > * Spring 3.x > * Spring 4.x > * .... > h3. Differences in having stacks > h4. Filtering commands > When you pick up a Stack, it gives you access or not to certain commands. For example, if you create a project with a Java EE 6 stack, you won't have access to any Batch, MVC... commands > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity > $ mvc-new-controller --named MyController // only available on EE7 > {code} > h4. Setting up command versions > When you pick up a Stack, it filters the commands that have the right version for the right stack. For example, if you create a Java EE 6 stack, you will get JPA 2.0 commands, for a Java EE 7 stack, the JPA 2.1 commands. Also, the {{version}} parameters will be disabled > {code:title=No stack} > $ project-new --named myproj > $ jpa-new-entity --named MyEntity --jpaVersion 2.1 > $ cdi-new-bean --named MyBean --cdiVersion 1.1 > {code} > {code:title=Java EE 6 stack} > $ project-new --named myproj --stack JavaEE6 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.0 > {code} > {code:title=Java EE 7 stack} > $ project-new --named myproj --stack JavaEE7 > $ jpa-new-entity --named MyEntity // no --jpaVersion because it is automatically set to 2.1 > $ jpa-new-converter --named MyConvert // JPA Converters are only available in 2.1 > {code} > h4. API to define a Stack > A stack could be defined with a fluent API such as : > {code} > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).excludes(SpringFacet) > stack("JavaEE7").includes(JavaEE7Facet).includes(JPA2.1Facet).allowsFeature(WildflySwarm) > stack("MyOwnStacks").includes(JavaEE7Stack).includes(MyFacet).includes(YourFacet) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2576) Configuration addon should store in properties file

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2576?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2576. ---------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.x Future) Resolution: Done > Configuration addon should store in properties file > --------------------------------------------------- > > Key: FORGE-2576 > URL: https://issues.jboss.org/browse/FORGE-2576 > Project: Forge > Issue Type: Enhancement > Components: Configuration > Affects Versions: 3.0.0.Beta1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 3.0.0.Beta2 > > > The configuration addon stores configuration information in XML format. > This makes it hard to read and error prone. > It would be nice if the Configuration were stored in a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2577) InputComponents.convertToUIInputValue should compare using labels as a last resort

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2577?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2577. ---------------------------------- Resolution: Done > InputComponents.convertToUIInputValue should compare using labels as a last resort > ---------------------------------------------------------------------------------- > > Key: FORGE-2577 > URL: https://issues.jboss.org/browse/FORGE-2577 > Project: Forge > Issue Type: Bug > Components: UI - API > Affects Versions: 3.0.0.Beta1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 3.0.0.Beta2 > > > {{org.jboss.forge.addon.ui.util.InputComponents.convertToUIInputValue(ConverterFactory, InputComponent<?, ?>, Object)}} should check if the provided value is contained in the value choices set before attempting to find using the associated ItemLabelConverter. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2577) InputComponents.convertToUIInputValue should compare using labels as a last resort

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2577: -------------------------------------- Summary: InputComponents.convertToUIInputValue should compare using labels as a last resort Key: FORGE-2577 URL: https://issues.jboss.org/browse/FORGE-2577 Project: Forge Issue Type: Bug Components: UI - API Affects Versions: 3.0.0.Beta1 Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 3.0.0.Beta2 {{org.jboss.forge.addon.ui.util.InputComponents.convertToUIInputValue(ConverterFactory, InputComponent<?, ?>, Object)}} should check if the provided value is contained in the value choices set before attempting to find using the associated ItemLabelConverter. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2182) Need an InputTypes.FILE_OR_DIRECTORY type

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2182?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-2182. ---------------------------------- Fix Version/s: (was: 3.x Future) Resolution: Won't Do Closing as Won't do since it is not supported on some IDEs > Need an InputTypes.FILE_OR_DIRECTORY type > ----------------------------------------- > > Key: FORGE-2182 > URL: https://issues.jboss.org/browse/FORGE-2182 > Project: Forge > Issue Type: Feature Request > Components: UI - API, UI - Eclipse, UI - IntelliJ IDEA, UI - NetBeans > Affects Versions: 2.13.0.Final > Reporter: Lincoln Baxter III > Assignee: George Gastaldi > > There is currently no way to hint to the IDE to allow an input to select a file OR directory in Eclipse. I assume this will also be problematic in other IDEs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2576) Configuration addon should store in properties file

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2576?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2576: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/core/pull/593 > Configuration addon should store in properties file > --------------------------------------------------- > > Key: FORGE-2576 > URL: https://issues.jboss.org/browse/FORGE-2576 > Project: Forge > Issue Type: Enhancement > Components: Configuration > Affects Versions: 3.0.0.Beta1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 3.x Future > > > The configuration addon stores configuration information in XML format. > This makes it hard to read and error prone. > It would be nice if the Configuration were stored in a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2576) Configuration addon should store in properties file

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2576?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-2576: ----------------------------------- Affects Version/s: 3.0.0.Beta1 > Configuration addon should store in properties file > --------------------------------------------------- > > Key: FORGE-2576 > URL: https://issues.jboss.org/browse/FORGE-2576 > Project: Forge > Issue Type: Enhancement > Components: Configuration > Affects Versions: 3.0.0.Beta1 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 3.x Future > > > The configuration addon stores configuration information in XML format. > This makes it hard to read and error prone. > It would be nice if the Configuration were stored in a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2576) Configuration addon should store in properties file

by George Gastaldi (JIRA)

George Gastaldi created FORGE-2576: -------------------------------------- Summary: Configuration addon should store in properties file Key: FORGE-2576 URL: https://issues.jboss.org/browse/FORGE-2576 Project: Forge Issue Type: Enhancement Components: Configuration Reporter: George Gastaldi Assignee: George Gastaldi Fix For: 3.x Future The configuration addon stores configuration information in XML format. This makes it hard to read and error prone. It would be nice if the Configuration were stored in a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues January 2016