[forge-issues] [JBoss JIRA] (FORGE-1733) Distinguish between similarly named parameters in Shell commands

[George Gastaldi (JIRA)]

     [ https://issues.jboss.org/browse/FORGE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Gastaldi reassigned FORGE-1733:
--------------------------------------

    Assignee: George Gastaldi

    
> Distinguish between similarly named parameters in Shell commands
> ----------------------------------------------------------------
>
>                 Key: FORGE-1733
>                 URL: https://issues.jboss.org/browse/FORGE-1733
>             Project: Forge
>          Issue Type: Feature Request
>          Components: UI - Shell
>    Affects Versions: 2.3.0.Final
>            Reporter: Vineet Reynolds
>            Assignee: George Gastaldi
>
> When I run this sequence of commands:
> {noformat}
> [tmp]$ project-new --named helloforge
> ***SUCCESS*** Project named 'helloforge' has been created.
> [helloforge]$ scaffold-setup --provider 
> Eclipse Link  Infinispan  Java EE  OpenJPA  Hibernate
> {noformat}
> I do not see the scaffold providers listed. I instead see the JPA providers. Both of these have the same parameter name in the shell: {{provider}}. The scaffold providers are shown only after I explicitly run {{jpa-setup}}:
> {noformat}
> [helloforge]$ jpa-setup --provider Hibernate --container JBOSS_EAP6 
> ***SUCCESS*** Persistence (JPA) is installed.
> [helloforge]$ scaffold-setup --provider 
> Faces  AngularJS  
> {noformat}
> Obviously this is confusing when I expect to see scaffold providers, which during installation can handle JPA setup.
> We could perhaps solve this by allowing the clients to rename parameter names when composing multiple such commands or navigation results from existing commands:
> {noformat}
> <vineetreynolds> We should allow these composite commands to rename parameters of the individual ones
> <vineetreynolds> somehow
> <gastaldi> Hmm
> <vineetreynolds> That way they'd be consistent
> <gastaldi> Not sure we can do that automatically
> <vineetreynolds> yeah
> <gastaldi> There are semantics involved
> <gastaldi> I think the best is to rename the parameter
> <vineetreynolds> It should be in some metadata provided by the composite command
> <gastaldi> Hmmm perhaps
> <vineetreynolds> We should assume that the composite command was written by someone who cannot change the original command
> <gastaldi> Right
> <vineetreynolds> Some callback to override parameter names might help
> <gastaldi> Yeah
> <vineetreynolds> Perhaps we could build it into NavigationResultBuilder
> <gastaldi> Like @AttributeOverrides in JPA
> <vineetreynolds> hmm yeah
> <gastaldi> But the NRB should know the conflicting parameters beforehand?
> <gastaldi> Hummm
> <vineetreynolds> it would be supplied by the client
> <gastaldi> Maybe yes
> <gastaldi> Yes
> <vineetreynolds> s/would/must
> {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