[JBoss JIRA] (FORGE-944) Thoughts on CLI renaming on Forge 2
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-944?page=com.atlassian.jira.plugin.... ]
Antonio Goncalves edited comment on FORGE-944 at 10/30/13 12:12 PM:
--------------------------------------------------------------------
Quickly checking the Forge 2 alpha 14 shell syntax and I can already see some difference with what it's written here :
* remove-an-addon, install-an-addon should be addon-remove addon-install if we follow the pattern (component)-(verb) (such as jpa-new)
* changing new-project to project-new : but as [~lincolnthree] says "yeah im not sure. that's a tough one :/"
was (Author: agoncal):
Quickly checking the Forge 2 alpha 14 shell syntax and I can already see some difference with what it's written here :
* remove-an-addon, install-an-addon should be addon-remove addon-install if we follow the pattern {component}-{verb} (such as jpa-new)
* changing new-project to project-new : but as [~lincolnthree] says "yeah im not sure. that's a tough one :/"
> Thoughts on CLI renaming on Forge 2
> -----------------------------------
>
> Key: FORGE-944
> URL: https://issues.jboss.org/browse/FORGE-944
> Project: Forge
> Issue Type: Enhancement
> Components: Brainstorming
> Affects Versions: 2.x Future
> Reporter: Antonio Goncalves
> Priority: Optional
> Labels: cli, renaming
> Fix For: 2.x Future
>
>
> I was talking about having CLI naming conventions on the forum and George and Lincoln suggested to add these ideas on a JIRA. So here is my humble contribution to record all the ideas about renaming commands.
> Disclaimer : I haven't used Forge for a long time, I've just started using it again, so some of the following ideas might not be accurate
> As a new comer in Forge I felt the commands were not that intuitive. I loved the following :
> {code}
> java new-enum-type
> java new-itnerface
> java new-class
> {code}
>
> So I was expecting to have something similar in all the other techologies, such as JPA :
> {code}
> jpa new-entity (instead of entity --named)
> jpa new-embedable
> jpa new-mapped-superclass --named Person
> jpa new-entity --named Vet --extends Person
> {code}
> Lincoln suggested having single-level command keywords only such as :
> {code}
> jpa-new-entity (instead of entity --named)
> jpa-new-embedable
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> {code}
> h3. Verbs and keywords
> When you look at the commansd, there are several common verbs and keywords than come often :
> {code}
> add : ejb-add-transaction-attribute
> new : beans-new-bean, faces-new-view, new-project (prefer project-new)
> list : list-web-resources, beans list-interceptors, beans list-alternatives, list-scaffold-providers
> setup : ejb setup, entity setup
> put : i18n put
> remove : i18n remove, project remove-property
> execute : execute-java
> set : maven set-groupid
> find : forge find-plugin
> install :
> update : forge update-abort, gitignore update-repo
> run : run-url
> info : analytics info
> {code}
> That brings several thoughts :
> * {{ls}} is used as well as {{list}}, should this be homogenize (e.g. beans-ls-interceptors)
> * {{rm}} is used as well as {{remove}}, should this be homogenize (e.g. i18n-rm, project-rm-property)
> * The difference between {{execute}} and {{run}} is not clear, should this be homogenize and only use one ?
> * Also there is {{execute}} and {{exec}}, this should be homogenize (e.g. {{execute-java}} and {{exec}})
> * Confusion between {{new}} and {{add}}. You create a new class with {{java-new-class}} and shouldn't you add a field and a method to existing class ({{java-add-field}} instead of {{java-new-field}})
> * Some confusion between {{maven}} and {{project}}
> * Is there any difference between {{set}} and {{update}} ? {{maven set-artifactid}} updates the already existing artifactId and {{gitignore update-repo}} updates an existing repo
> * we use {{field}} (e.g. {{java-add-field}}) and then property ({{constraint Future --onProperty date}}), it should be fiels ({{constraint Future --onField date}})
> In many commands you find a type argument such as ({{type}}, {{scaffoldType}}, {{fieldType}} :
> {code}
> scaffold setup --scaffoldType faces
> field manyToMany --named specialties --fieldType ~.model.Specialty.java
> field temporal --type DATE --named date
> {code}
> Why not having only {{type}} in all the cases :
> {code}
> scaffold-setup --type faces
> jpa-add-field manyToMany --named specialties --type ~.model.Specialty.java
> jpa-add-field temporal --named date --type DATE
> {code}
> h3. Grammar
> The CLI grammar could look like this :
> {code}
> command = shell | forge command ;
> forge command = technology,-action,[-artifact] [{--argument value}] ;
> shell = cat | cd | cp | edit | find | grep | ls ...
> technology = project | scaffold | beans | constraint | java | jpa | i18n | ejb ...
> action = add | new | ls | rm | setup ...
> artifact = providers | interceptors | class | filter...
> argument = named | onField | type | extends
> {code}
> h3. Examples
> So if we take that grammar and apply single-level command keywords, we could have things like that :
> {code}
> mkdir
> ls
> ls-commands -all
> project-new --named MyPro
> scaffold-ls-providers
> scaffold-templates --scaffoldType faces
> beans-ls-interceptors
> constraint-new-constraint --named MyConstraint
> constraint-add-constraint MyConstraint --onField MyProp
> java-new-class --named MyClass
> java-add-field 'private List<Vet> vets'
> java-add-method 'public List<Vet> getVetList() {return null;}'
> java-add-annotation --type XmlRootElement --onClass MyClass
> java-add-annotation --type XmlAttribute --onField MyProp
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> jpa-add-field manyToOne --named owner --type ~.model.Owner.java
> i18n-add-locale --locale PT
> ejb-new-stateless --named MyStateless
> ejb-new-singleton --named MySingleton --implements MyInterface AndAnotherInterface
> ejb-add-transaction-attribute --type NEVER
> ejb-add-transaction-attribute --type NEVER --onMethod MyNeverMethod
> faces-new-view --named MyView
> faces-set-project-stage --stage PRODUCTION
> servlet-new-filter --named MyFilter
> rest-new-endpoint --named MyEndpoint --extends MyRestExtension
> mvn-build --notest
> {code}
> Scaffolding is a bit tricky because it's extendable and you could end up with
> {code}
> scaffold-ui-from-entity ~.model.*
> scaffold-rest-endpoint-from-entity ~.model.*
> scaffold-dao-from-entity ~.model.*
> scaffold-ejb-service-from-dao ~.dao.*
> scaffold-rest-endpoint-from-dao ~.dao.*
> {code}
> Or something like that
> {code}
> scaffold --ui --from-entity ~.model.*
> scaffold --rest-endpoint --from-entity ~.model.*
> scaffold --dao --from-entity ~.model.*
> scaffold --ejb-service --from-dao ~.dao.*
> scaffold --rest-endpoint --from-dao ~.dao.*
> {code}
> Here are my 2 cents thoughts on a topic that I'm discovering. As you all know, naming is really important and should be looked at carefully. Let's use this JIRA to exchange ideas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (FORGE-944) Thoughts on CLI renaming on Forge 2
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-944?page=com.atlassian.jira.plugin.... ]
Antonio Goncalves commented on FORGE-944:
-----------------------------------------
Quickly checking the Forge 2 alpha 14 shell syntax and I can already see some difference with what it's written here :
* remove-an-addon, install-an-addon should be addon-remove addon-install if we follow the pattern {component}-{verb} (such as jpa-new)
* changing new-project to project-new : but as [~lincolnthree] says "yeah im not sure. that's a tough one :/"
> Thoughts on CLI renaming on Forge 2
> -----------------------------------
>
> Key: FORGE-944
> URL: https://issues.jboss.org/browse/FORGE-944
> Project: Forge
> Issue Type: Enhancement
> Components: Brainstorming
> Affects Versions: 2.x Future
> Reporter: Antonio Goncalves
> Priority: Optional
> Labels: cli, renaming
> Fix For: 2.x Future
>
>
> I was talking about having CLI naming conventions on the forum and George and Lincoln suggested to add these ideas on a JIRA. So here is my humble contribution to record all the ideas about renaming commands.
> Disclaimer : I haven't used Forge for a long time, I've just started using it again, so some of the following ideas might not be accurate
> As a new comer in Forge I felt the commands were not that intuitive. I loved the following :
> {code}
> java new-enum-type
> java new-itnerface
> java new-class
> {code}
>
> So I was expecting to have something similar in all the other techologies, such as JPA :
> {code}
> jpa new-entity (instead of entity --named)
> jpa new-embedable
> jpa new-mapped-superclass --named Person
> jpa new-entity --named Vet --extends Person
> {code}
> Lincoln suggested having single-level command keywords only such as :
> {code}
> jpa-new-entity (instead of entity --named)
> jpa-new-embedable
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> {code}
> h3. Verbs and keywords
> When you look at the commansd, there are several common verbs and keywords than come often :
> {code}
> add : ejb-add-transaction-attribute
> new : beans-new-bean, faces-new-view, new-project (prefer project-new)
> list : list-web-resources, beans list-interceptors, beans list-alternatives, list-scaffold-providers
> setup : ejb setup, entity setup
> put : i18n put
> remove : i18n remove, project remove-property
> execute : execute-java
> set : maven set-groupid
> find : forge find-plugin
> install :
> update : forge update-abort, gitignore update-repo
> run : run-url
> info : analytics info
> {code}
> That brings several thoughts :
> * {{ls}} is used as well as {{list}}, should this be homogenize (e.g. beans-ls-interceptors)
> * {{rm}} is used as well as {{remove}}, should this be homogenize (e.g. i18n-rm, project-rm-property)
> * The difference between {{execute}} and {{run}} is not clear, should this be homogenize and only use one ?
> * Also there is {{execute}} and {{exec}}, this should be homogenize (e.g. {{execute-java}} and {{exec}})
> * Confusion between {{new}} and {{add}}. You create a new class with {{java-new-class}} and shouldn't you add a field and a method to existing class ({{java-add-field}} instead of {{java-new-field}})
> * Some confusion between {{maven}} and {{project}}
> * Is there any difference between {{set}} and {{update}} ? {{maven set-artifactid}} updates the already existing artifactId and {{gitignore update-repo}} updates an existing repo
> * we use {{field}} (e.g. {{java-add-field}}) and then property ({{constraint Future --onProperty date}}), it should be fiels ({{constraint Future --onField date}})
> In many commands you find a type argument such as ({{type}}, {{scaffoldType}}, {{fieldType}} :
> {code}
> scaffold setup --scaffoldType faces
> field manyToMany --named specialties --fieldType ~.model.Specialty.java
> field temporal --type DATE --named date
> {code}
> Why not having only {{type}} in all the cases :
> {code}
> scaffold-setup --type faces
> jpa-add-field manyToMany --named specialties --type ~.model.Specialty.java
> jpa-add-field temporal --named date --type DATE
> {code}
> h3. Grammar
> The CLI grammar could look like this :
> {code}
> command = shell | forge command ;
> forge command = technology,-action,[-artifact] [{--argument value}] ;
> shell = cat | cd | cp | edit | find | grep | ls ...
> technology = project | scaffold | beans | constraint | java | jpa | i18n | ejb ...
> action = add | new | ls | rm | setup ...
> artifact = providers | interceptors | class | filter...
> argument = named | onField | type | extends
> {code}
> h3. Examples
> So if we take that grammar and apply single-level command keywords, we could have things like that :
> {code}
> mkdir
> ls
> ls-commands -all
> project-new --named MyPro
> scaffold-ls-providers
> scaffold-templates --scaffoldType faces
> beans-ls-interceptors
> constraint-new-constraint --named MyConstraint
> constraint-add-constraint MyConstraint --onField MyProp
> java-new-class --named MyClass
> java-add-field 'private List<Vet> vets'
> java-add-method 'public List<Vet> getVetList() {return null;}'
> java-add-annotation --type XmlRootElement --onClass MyClass
> java-add-annotation --type XmlAttribute --onField MyProp
> jpa-new-mapped-superclass --named Person
> jpa-new-entity --named Vet --extends Person
> jpa-add-field manyToOne --named owner --type ~.model.Owner.java
> i18n-add-locale --locale PT
> ejb-new-stateless --named MyStateless
> ejb-new-singleton --named MySingleton --implements MyInterface AndAnotherInterface
> ejb-add-transaction-attribute --type NEVER
> ejb-add-transaction-attribute --type NEVER --onMethod MyNeverMethod
> faces-new-view --named MyView
> faces-set-project-stage --stage PRODUCTION
> servlet-new-filter --named MyFilter
> rest-new-endpoint --named MyEndpoint --extends MyRestExtension
> mvn-build --notest
> {code}
> Scaffolding is a bit tricky because it's extendable and you could end up with
> {code}
> scaffold-ui-from-entity ~.model.*
> scaffold-rest-endpoint-from-entity ~.model.*
> scaffold-dao-from-entity ~.model.*
> scaffold-ejb-service-from-dao ~.dao.*
> scaffold-rest-endpoint-from-dao ~.dao.*
> {code}
> Or something like that
> {code}
> scaffold --ui --from-entity ~.model.*
> scaffold --rest-endpoint --from-entity ~.model.*
> scaffold --dao --from-entity ~.model.*
> scaffold --ejb-service --from-dao ~.dao.*
> scaffold --rest-endpoint --from-dao ~.dao.*
> {code}
> Here are my 2 cents thoughts on a topic that I'm discovering. As you all know, naming is really important and should be looked at carefully. Let's use this JIRA to exchange ideas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (FORGE-1299) list-command missing
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-1299:
----------------------------------------
Summary: list-command missing
Key: FORGE-1299
URL: https://issues.jboss.org/browse/FORGE-1299
Project: Forge
Issue Type: Feature Request
Components: UI - Shell
Affects Versions: 2.0.0.Alpha14
Reporter: Antonio Goncalves
{{list-command}} and {{list-command --all}} are missing in the CLI. That is quite an important one to have an idea of the commands.
But following the issue [FORGE-944] it should be {{command-list}} instead of {{list-command}} (component-verb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (FORGEPLUGINS-133) Arquillian Forge plugin installation fails on Forge 1.3.3.FINAL
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-133?page=com.atlassian.jira.... ]
Vineet Reynolds commented on FORGEPLUGINS-133:
----------------------------------------------
This is actually a duplicate of FORGE-1134.
> Arquillian Forge plugin installation fails on Forge 1.3.3.FINAL
> ---------------------------------------------------------------
>
> Key: FORGEPLUGINS-133
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-133
> Project: Forge Plugins
> Issue Type: Bug
> Components: Arquillian Plugin
> Environment: Forge 1.3.3.Final
> Reporter: Vineet Reynolds
> Assignee: Aslak Knutsen
>
> Cloned from : https://github.com/forge/plugin-arquillian/issues/31
> Plugin install fails with forge 1.3.3.FINAL. I am trying to follow the arquillian tutorial.
> {noformat}
> forge install-plugin arquillian
> Connecting to remote repository [https://raw.github.com/forge/plugin-repository/master/repository.yaml]... connected!
> ***INFO*** Preparing to install plugin: arquillian
> ***INFO*** Checking out plugin source files to [/tmp/forgetemp2717179280024408314] via 'git'
> ***INFO*** Switching to branch/tag [refs/heads/1.0.6.Final]
> ***INFO*** Project found
> ***INFO*** Name: arquillian-plugin
> ***INFO*** Version: 1.0.0-SNAPSHOT
> ***INFO*** Type: Java Application
> ? The project does not appear to be a Forge Plugin Project, install anyway? [y/N] y
> ***INFO*** Project found
> ***INFO*** Name: arquillian-demo
> ***INFO*** Version: 1.0.0-SNAPSHOT
> ***INFO*** Type: Java Application
> ***INFO*** Cleaning up temp workspace [/tmp/forgetemp2717179280024408314]
> Wrote /home/dbeer/.forge/httpsrawgithubcomforgepluginrepositorymasterrepositoryyaml.yaml
> Deleted /tmp/forgetemp2717179280024408314
> ***ERROR*** Exception encountered: (type "set VERBOSE false" to disable stack traces)
> java.lang.NullPointerException
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.buildFromCurrentProject(ForgePlugin.java:625)
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromGit(ForgePlugin.java:414)
> at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromIndex(ForgePlugin.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.forge.shell.command.Execution.perform(Execution.java:160)
> at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:109)
> at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:47)
> at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:795)
> at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:818)
> at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:608)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
> at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
> at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
> at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:186)
> at java.lang.Thread.run(Thread.java:724)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months