[
https://issues.jboss.org/browse/FORGE-1733?page=com.atlassian.jira.plugin...
]
Vineet Reynolds updated FORGE-1733:
-----------------------------------
Description:
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}
was:
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.
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
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