[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:
-------------------------------------
Fix Version/s: 3.x Future
(was: 2.x Future)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 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:
-------------------------------------
Parent: FORGE-2277
Issue Type: Sub-task (was: Task)
> 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: 2.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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (FORGE-2516) Adding "features" to scaffolding
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2516?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2516:
-------------------------------------
Description:
{quote}
agoncal Last week I gave 2 talks only in Forge and 2 talks on CDI using Forge
agoncal The interesting feedbacks I had were :
agoncal * not enough scaffolding strategy
agoncal As we've already talked, being able to scaffold different architecture is important
gastaldi yes
agoncal But also (and that was an interesting feedback) having more "business" scaffolding
gastaldi you mean scaffolding for a homegrown architecture?
gastaldi what do you mean?
agoncal Typically, you want to scaffold an app, you go faces-scaffold
agoncal But if you want an app with login, you could go faces-scaffold --with-login
agoncal (that's a common use case)
agoncal And the good old shopping cart came along :
agoncal faces-scaffold --with-shopping-cart
agoncal And of course :
gastaldi hm
agoncal faces-scaffold --with-shopping-cart --with-login
gastaldi this looks very specific
agoncal The idea is to be able to scaffold common use case (a bit like what you did with generating design patterns, but in a larger scale)
gastaldi interesting
gastaldi maybe we could split these use cases into scripts
gastaldi run shopping-cart-faces.sh
agoncal Yes. In fact what Forge does is generate a CRUD app based on Entities, but that could be just another option :
agoncal faces-scaffold --with-crud
agoncal Yes but how do we integrate it nicelly in the top menu bar ?
gastaldi or something like: faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
agoncal Yes, "feature" is good naming
agoncal And features would be available for a specific scaffolding :
agoncal faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
gastaldi and we can make that pluggable
agoncal rest-scaffold --featuring LOGIN, SECURITY
{quote}
was:
agoncal Last week I gave 2 talks only in Forge and 2 talks on CDI using Forge
15:59:01 agoncal The interesting feedbacks I had were :
15:59:11 agoncal * not enough doc/tutorial
15:59:20 gastaldi yeah, that's a shame :(
15:59:21 agoncal * not enough scaffolding strategy
15:59:47 agoncal As we've already talked, being able to scaffold different architecture is important
15:59:53 gastaldi yes
16:00:07 agoncal But also (and that was an interesting feedback) having more "business" scaffolding
16:00:24 gastaldi you mean scaffolding for a homegrown architecture?
16:00:34 gastaldi what do you mean?
16:00:40 agoncal Typically, you want to scaffold an app, you go faces-scaffold
16:01:06 agoncal But if you want an app with login, you could go faces-scaffold --with-login
16:01:11 agoncal (that's a common use case)
16:01:20 agoncal And the good old shopping cart came along :
16:01:32 agoncal faces-scaffold --with-shopping-cart
16:01:35 agoncal And of course :
16:01:44 gastaldi hm
16:01:45 agoncal faces-scaffold --with-shopping-cart --with-login
16:01:45 kopcheski joined the channel.
16:02:44 gastaldi this looks very specific
16:02:45 agoncal The idea is to be able to scaffold common use case (a bit like what you did with generating design patterns, but in a larger scale)
16:02:53 gastaldi interesting
16:03:24 gastaldi maybe we could split these use cases into scripts
16:03:32 gastaldi run shopping-cart-faces.sh
16:03:48 agoncal Yes. In fact what Forge does is generate a CRUD app based on Entities, but that could be just another option :
16:03:56 agoncal aces-scaffold --with-crud
16:04:30 agoncal Yes but how do we integrate it nicelly in the top menu bar ?
16:04:30 gastaldi or something like: faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
16:04:46 agoncal Yes, "feature" is good naming
16:05:09 agoncal And features would be available for a specific scaffolding :
16:05:15 agoncal faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
16:05:21 gastaldi and we can make that pluggable
16:05:24 agoncal rest-scaffold --featuring LOGIN, SECURITY
> Adding "features" to scaffolding
> --------------------------------
>
> Key: FORGE-2516
> URL: https://issues.jboss.org/browse/FORGE-2516
> Project: Forge
> Issue Type: Sub-task
> Components: Scaffold
> Affects Versions: 2.20.0.Final
> Reporter: Antonio Goncalves
> Priority: Minor
> Fix For: 3.x Future
>
>
> {quote}
> agoncal Last week I gave 2 talks only in Forge and 2 talks on CDI using Forge
> agoncal The interesting feedbacks I had were :
> agoncal * not enough scaffolding strategy
> agoncal As we've already talked, being able to scaffold different architecture is important
> gastaldi yes
> agoncal But also (and that was an interesting feedback) having more "business" scaffolding
> gastaldi you mean scaffolding for a homegrown architecture?
> gastaldi what do you mean?
> agoncal Typically, you want to scaffold an app, you go faces-scaffold
> agoncal But if you want an app with login, you could go faces-scaffold --with-login
> agoncal (that's a common use case)
> agoncal And the good old shopping cart came along :
> agoncal faces-scaffold --with-shopping-cart
> agoncal And of course :
> gastaldi hm
> agoncal faces-scaffold --with-shopping-cart --with-login
> gastaldi this looks very specific
> agoncal The idea is to be able to scaffold common use case (a bit like what you did with generating design patterns, but in a larger scale)
> gastaldi interesting
> gastaldi maybe we could split these use cases into scripts
> gastaldi run shopping-cart-faces.sh
> agoncal Yes. In fact what Forge does is generate a CRUD app based on Entities, but that could be just another option :
> agoncal faces-scaffold --with-crud
> agoncal Yes but how do we integrate it nicelly in the top menu bar ?
> gastaldi or something like: faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
> agoncal Yes, "feature" is good naming
> agoncal And features would be available for a specific scaffolding :
> agoncal faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
> gastaldi and we can make that pluggable
> agoncal rest-scaffold --featuring LOGIN, SECURITY
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (FORGE-2516) Adding "features" to scaffolding
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2516:
----------------------------------------
Summary: Adding "features" to scaffolding
Key: FORGE-2516
URL: https://issues.jboss.org/browse/FORGE-2516
Project: Forge
Issue Type: Sub-task
Components: Scaffold
Affects Versions: 2.20.0.Final
Reporter: Antonio Goncalves
Priority: Minor
Fix For: 3.x Future
agoncal Last week I gave 2 talks only in Forge and 2 talks on CDI using Forge
15:59:01 agoncal The interesting feedbacks I had were :
15:59:11 agoncal * not enough doc/tutorial
15:59:20 gastaldi yeah, that's a shame :(
15:59:21 agoncal * not enough scaffolding strategy
15:59:47 agoncal As we've already talked, being able to scaffold different architecture is important
15:59:53 gastaldi yes
16:00:07 agoncal But also (and that was an interesting feedback) having more "business" scaffolding
16:00:24 gastaldi you mean scaffolding for a homegrown architecture?
16:00:34 gastaldi what do you mean?
16:00:40 agoncal Typically, you want to scaffold an app, you go faces-scaffold
16:01:06 agoncal But if you want an app with login, you could go faces-scaffold --with-login
16:01:11 agoncal (that's a common use case)
16:01:20 agoncal And the good old shopping cart came along :
16:01:32 agoncal faces-scaffold --with-shopping-cart
16:01:35 agoncal And of course :
16:01:44 gastaldi hm
16:01:45 agoncal faces-scaffold --with-shopping-cart --with-login
16:01:45 kopcheski joined the channel.
16:02:44 gastaldi this looks very specific
16:02:45 agoncal The idea is to be able to scaffold common use case (a bit like what you did with generating design patterns, but in a larger scale)
16:02:53 gastaldi interesting
16:03:24 gastaldi maybe we could split these use cases into scripts
16:03:32 gastaldi run shopping-cart-faces.sh
16:03:48 agoncal Yes. In fact what Forge does is generate a CRUD app based on Entities, but that could be just another option :
16:03:56 agoncal aces-scaffold --with-crud
16:04:30 agoncal Yes but how do we integrate it nicelly in the top menu bar ?
16:04:30 gastaldi or something like: faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
16:04:46 agoncal Yes, "feature" is good naming
16:05:09 agoncal And features would be available for a specific scaffolding :
16:05:15 agoncal faces-scaffold --featuring LOGIN, SHOPPING_CART, CRUD
16:05:21 gastaldi and we can make that pluggable
16:05:24 agoncal rest-scaffold --featuring LOGIN, SECURITY
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (FORGE-2515) project-new prints null in the CLI
by Claus Ibsen (JIRA)
[ https://issues.jboss.org/browse/FORGE-2515?page=com.atlassian.jira.plugin... ]
Claus Ibsen commented on FORGE-2515:
------------------------------------
I create a new project and name it foo and leave all other fields as default by pressing ENTER
{code}
davsclaus:/opt/forge-distribution-2.20.0.Final/$ bin/forge
Using Forge at /opt/forge-distribution-2.20.0.Final
_____
| ___|__ _ __ __ _ ___
| |_ / _ \| `__/ _` |/ _ \ \\
| _| (_) | | | (_| | __/ //
|_| \___/|_| \__, |\___|
|__/
JBoss Forge, version [ 2.20.0.Final ] - JBoss, by Red Hat, Inc. [ http://forge.jboss.org ]
[forge-distribution-2.20.0.Final]$ project-new
***INFO*** Required inputs not satisfied, entering interactive mode
* Project namenull: foo
? Top level packagenull [org.foo]:
? versionnull [1.0.0-SNAPSHOT]:
? Final namenull:
? Project locationnull [/opt/forge-distribution-2.20.0.Final]:
[0] (x) war
[1] ( ) jar
[2] ( ) parent
[3] ( ) addon
[4] ( ) resource-jar
[5] ( ) ear
[6] ( ) from-archetype
Press <ENTER> to confirm, or <CTRL>+C to cancel.
* Project type: [0-6]
[0] (x) Maven
Press <ENTER> to confirm, or <CTRL>+C to cancel.
* Build system: [0]
***SUCCESS*** Project named 'foo' has been created.
{code}
> project-new prints null in the CLI
> ----------------------------------
>
> Key: FORGE-2515
> URL: https://issues.jboss.org/browse/FORGE-2515
> Project: Forge
> Issue Type: Bug
> Affects Versions: 2.20.0.Final
> Reporter: Claus Ibsen
> Assignee: George Gastaldi
> Priority: Minor
> Fix For: 2.20.1.Final, 3.0.0.Alpha1
>
>
> Notice the null in the label output for the project name
> {code}
> [forge-distribution-2.20.0.Final]$ project-new
> ***INFO*** Required inputs not satisfied, entering interactive mode
> ***INFO*** Required inputs not satisfied, entering interactive mode
> * Project namenull: foo
> ? Top level packagenull [org.foo]:
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months