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 Fix For: 2.x Future 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}