[JBoss JIRA] (FORGE-2573) Introduce Optional<F> Faceted.getOptionalFacet(Class<F>)
by George Gastaldi (JIRA)
George Gastaldi created FORGE-2573:
--------------------------------------
Summary: Introduce Optional<F> Faceted.getOptionalFacet(Class<F>)
Key: FORGE-2573
URL: https://issues.jboss.org/browse/FORGE-2573
Project: Forge
Issue Type: Enhancement
Components: Facets
Affects Versions: 3.0.0.Beta1
Reporter: George Gastaldi
Assignee: George Gastaldi
Fix For: 3.0.0.CR1
It would be nice to have a method that would return a JDK 8's {{java.util.Optional}} when getting a facet
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[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:
----------------------------------------
Hi Max,
I modeled a Stack as a Facet for simplicity in querying the project for the existing installed stacks: Eg. {{project.getFacet(StackFacet.class)}} would return all the stacks enabled in a given project.
Moreover, as you can see in the available methods in StackFacet, it supports checking if a given Facet (which could be another stack) is supported for a given stack, thus allowing the concept of Stacks of Stacks as you mentioned.
However as this is an early prototype, I am open to suggestions regarding the implementation.
> 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)
8 years, 11 months
[JBoss JIRA] (FORGE-2316) Brainstorming on introducing "Stacks"
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/FORGE-2316?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on FORGE-2316:
--------------------------------------------
just a comment for my clarification - I thought Stacks would be something that managed one or more facets ?
Is that what Stack does but is still seen itself as a Facet ? Could one have Stack's of Stack's then ?
> 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)
8 years, 11 months
[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 edited comment on FORGE-2316 at 1/6/16 6:46 AM:
----------------------------------------------------------------
In my prototype, Stacks are treated as Facets, so each stack can be implemented as a Facet and will be chosen in the Project: New.
There is a {{boolean supports(Facet)}} method in the StackFacet implementation (JavaEE6FacetImpl and JavaEE7FacetImpl currently) that would tell if a Facet is supported. See the javadoc in https://github.com/forge/core/blob/stacks_as_facet/projects/api/src/main/...
was (Author: gastaldi):
In my prototype, Stacks are treated as Facets, so each stack can be implemented as a Facet and will be chosen in the Project: New.
There is a {{boolean supports(Facet)}} method in the StackFacet implementation (JavaEE6FacetImpl and JavaEE7FacetImpl currently) that would tell if a Facet is supported. See the javadoc in https://github.com/forge/core/blob/stacks_prototype/projects/api/src/main...
> 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)
8 years, 11 months
[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 edited comment on FORGE-2316 at 1/6/16 6:45 AM:
----------------------------------------------------------------
I have pushed an early prototype on this in https://github.com/forge/core/tree/stacks_as_facet
Let me know your thoughts
was (Author: gastaldi):
I have pushed an early prototype on this in https://github.com/forge/core/tree/stacks_prototype
Let me know your thoughts
> 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)
8 years, 11 months
[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:
----------------------------------------
In my prototype, Stacks are treated as Facets, so each stack can be implemented as a Facet and will be chosen in the Project: New.
There is a {{boolean supports(Facet)}} method in the StackFacet implementation (JavaEE6FacetImpl and JavaEE7FacetImpl currently) that would tell if a Facet is supported. See the javadoc in https://github.com/forge/core/blob/stacks_prototype/projects/api/src/main...
> 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)
8 years, 11 months
[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:
----------------------------------------
I have pushed an early prototype on this in https://github.com/forge/core/tree/stacks_prototype
Let me know your thoughts
> 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)
8 years, 11 months
[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 updated FORGE-2316:
-------------------------------------
Description:
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}
was:
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}
> 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)
8 years, 11 months
[JBoss JIRA] (FORGE-2371) Use <h:graphicImage> instead of <img> in JSF scaffolding
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2371?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-2371.
----------------------------------
Fix Version/s: 3.0.0.CR1
(was: 3.x Future)
Assignee: George Gastaldi
Resolution: Done
> Use <h:graphicImage> instead of <img> in JSF scaffolding
> --------------------------------------------------------
>
> Key: FORGE-2371
> URL: https://issues.jboss.org/browse/FORGE-2371
> Project: Forge
> Issue Type: Sub-task
> Components: Scaffold
> Affects Versions: 2.16.2.Final
> Reporter: Antonio Goncalves
> Assignee: George Gastaldi
> Fix For: 3.0.0.CR1
>
>
> In the JSF scaffolding, it would be better to use the JSF <h:graphicImage> instead of <img> (to have a more JSF consistent code). There are two pages that would need to get changed :
> In the {{pageTemplate.xhtml}}, we should replace
> {code}
> <img src='#{resource["forge-logo.png"]}' alt="Forge... get hammered" border="0" />
> {code}
> With :
> {code}
> <h:graphicImage value="#{resource['forge-logo.png']}" alt="Forge... get hammered" border="0" />
> {code}
> In the {{error.xhtml}}, we should replace
> {code}
> <img src='#{resource["jboss-community.png"]}' alt="JBoss and JBoss Community" width="254" height="31" border="0" />
> {code}
> With :
> {code}
> <h:graphicImage value="#{resource['jboss-community.png']}" alt="JBoss and JBoss Community" width="254" height="31" border="0" />
> {code}
> Add add {{xmlns:h="http://java.sun.com/jsf/html"}} to the namespaces.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months