Spring Roo
  1. Spring Roo
  2. ROO-2955

create addon to adjust/compose existing roo commands according to project's standards/guidelines.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.0.RC1
    • Fix Version/s: 1.2.6.RELEASE
    • Component/s: @ ROO SHELL
    • Labels:
      None

      Description

      Roo is becoming more and more powerful, which is great, but also means more and more options to users how to use Roo.

      The proposed addon should enable

      • teams working on large projects to ensure streamlined Roo usage according to their project's standards and guidelines
      • single users to define the approach they usually take in one file to reuse it over multiple projects

      Examples use cases:

      • A team does not want to use the Active Record pattern for entities, but always wants developers to specifiy "--activeRecord false", and create a JPA repository based on every new entity.
      • A user always uses a certain project structure to create web projects: a Maven project with 2 modules called "domain" and "web". He wants to be able to reuse this structure with the project command, and make sure that the shell automatically focuses on the correct module for certain commands (e.g. entity > domain, web mvc > web).

      Basic implementation idea:
      The Roo command would be intercepted and transformed to a new set of commands according to user specifications (e.g. configuration file), if any exist for that particular command. The shell would then execute this transformed set of commands.

      Initial set of proposed features:

      • Define reusable project structures to use with the "project" command
      • Define default target modules for commands.
      • Define default values for command arguments.
      • Define chains of commands, either triggered by an existing command or composed by an alias
      • Define naming conventions.

        Activity

        Hide
        Vladimir Tihomirov added a comment -

        We implemented an addon that offers the described features and requires only minimal changes to the existing Roo Shell implementation.

        These are the concepts we defined for the addon (terminology open to suggestions):

        Tailor
        Proposed name for the addon, to mean that users can use this to “tailor” Roo to their purposes. There can be multiple tailor definitions loaded in the shell, the user can currently activate only one of them at a time.
        CommandConfiguration
        Each Tailor configuration has one or more CommandConfigurations. A CommandConfiguration defines a set of Actions that are triggered whenever a certain command is executed.
        Action
        A transformation step to be applied to the command defined in a CommandConfiguration. Each Action type defines a set of parameters that can be set in a tailor definition. The Tailor addon could be extended with more and more Action types by the community over time.

        A Tailor configuration can be specified in two ways with the current implementation:

        • Directly in Java (requires creation and installation of a new addon)
        • XML configuration file (no addon development required)

        The syntax is a thin layer on the concepts explained above, it would be easy to implement other ways to instantiate Tailor configurations.

        Examples
        Define reusable project structures to use with the “project” command.
        Define chains of commands.

        <tailor name="mywebstyle" description="Standards for web projects with 2 modules">
           <config command="project">
              <action type="defaultvalue" argument="packaging" value="pom" />
              <action type="executeself" />
              <action type="executecommand" command="module create --moduleName ${projectName}-domain --topLevelPackage ${topLevelPackage}"/>
              <action type="focusmodule" module="~"/>
              <action type="executecommand" command="module create --moduleName ${projectName}-web --topLevelPackage ${topLevelPackage} --packaging war"/>
              <action type="focusmodule" module="${projectName}-domain"/>
           </config>
        </tailor>
        

        Shell:

        tailor activate --name mywebstyle
        project --topLevelPackage com.foo.sample --projectName myapp
        

        >> log.roo:

        tailor activate --name mywebstyle
        project --topLevelPackage com.foo.sample --projectName mywebapp --packaging pom
        module create --moduleName myapp-domain --topLevelPackage com.foo.sample
        module focus --moduleName ~
        module create --moduleName myapp-web --topLevelPackage com.foo.sample --packaging war
        module focus --moduleName myapp-domain
        

        Define default target modules for commands.
        Define default values for command arguments.

        <config command="entity jpa">
           <action type="focusmodule" module="domain"/>
           <action type="defaultvalue" argument="--activeRecord" value="false"/>
           <action type="executeself"/>
        </config>
        

        Shell:

        entity jpa --class ~.Customer

        >> log.roo:

        module focus --moduleName webapp-domain
        entity jpa --class ~.Customer --activeRecord false
        
        Show
        Vladimir Tihomirov added a comment - We implemented an addon that offers the described features and requires only minimal changes to the existing Roo Shell implementation. These are the concepts we defined for the addon (terminology open to suggestions): Tailor Proposed name for the addon, to mean that users can use this to “tailor” Roo to their purposes. There can be multiple tailor definitions loaded in the shell, the user can currently activate only one of them at a time. CommandConfiguration Each Tailor configuration has one or more CommandConfigurations. A CommandConfiguration defines a set of Actions that are triggered whenever a certain command is executed. Action A transformation step to be applied to the command defined in a CommandConfiguration. Each Action type defines a set of parameters that can be set in a tailor definition. The Tailor addon could be extended with more and more Action types by the community over time. A Tailor configuration can be specified in two ways with the current implementation: Directly in Java (requires creation and installation of a new addon) XML configuration file (no addon development required) The syntax is a thin layer on the concepts explained above, it would be easy to implement other ways to instantiate Tailor configurations. Examples Define reusable project structures to use with the “project” command. Define chains of commands. <tailor name= "mywebstyle" description= "Standards for web projects with 2 modules" > <config command= "project" > <action type= "defaultvalue" argument= "packaging" value= "pom" /> <action type= "executeself" /> <action type= "executecommand" command= "module create --moduleName ${projectName}-domain --topLevelPackage ${topLevelPackage}" /> <action type= "focusmodule" module= "~" /> <action type= "executecommand" command= "module create --moduleName ${projectName}-web --topLevelPackage ${topLevelPackage} --packaging war" /> <action type= "focusmodule" module= "${projectName}-domain" /> </config> </tailor> Shell: tailor activate --name mywebstyle project --topLevelPackage com.foo.sample --projectName myapp >> log.roo: tailor activate --name mywebstyle project --topLevelPackage com.foo.sample --projectName mywebapp --packaging pom module create --moduleName myapp-domain --topLevelPackage com.foo.sample module focus --moduleName ~ module create --moduleName myapp-web --topLevelPackage com.foo.sample --packaging war module focus --moduleName myapp-domain Define default target modules for commands. Define default values for command arguments. <config command= "entity jpa" > <action type= "focusmodule" module= "domain" /> <action type= "defaultvalue" argument= "--activeRecord" value= "false" /> <action type= "executeself" /> </config> Shell: entity jpa --class ~.Customer >> log.roo: module focus --moduleName webapp-domain entity jpa --class ~.Customer --activeRecord false
        Hide
        Vladimir Tihomirov added a comment -

        This approach can even be used to define command aliases or command extensions, as long as there are Actions available that support what the user wants to do with that command.

        Let’s say a user wants to optionally specify the names of the domain and web modules every time he executes the project command. He wants to use arguments like "-domainName" and "-webName", both of which are not valid arguments for the existing "project" command. Without having to change anything in Roo’s implementation, he can do that with a tailor configuration like this:

        <config command="project">
           <action type="defaultvalue" argument="packaging" value="pom"/>
           <action type="defaultvalue" argument="domainName" value="${projectName}-domain"/>
           <action type="defaultvalue" argument="webName" value="${projectName}-web"/>
           <action type="executeself" without="domainName,webName"/>
           <action type="executecommand" command="module create --moduleName ${domainName} --topLevelPackage ${topLevelPackage}"/>
           <action type="focusmodule" module="~"/>
           <action type="executecommand" command="module create --moduleName ${webName} --topLevelPackage ${topLevelPackage} --packaging war"/>
        </config>
        

        The option for the executeself action without="domainName,webName" makes sure that the Tailor removes these options from the original command before it is sent back to the Roo shell. So the shell does not even notice that there were “invalid” arguments for the project command, but the other actions in the Tailor configuration evaluated them to do the command transformation ($

        {domainName}

        , $

        {webName}

        ).

        Shell:

        project --topLevelPackage com.foo.sample --projectName myapp --webName myapp-presentation

        >> log.roo:

        project --topLevelPackage com.foo.sample --projectName mywebapp --packaging pom
        module create --moduleName myapp-domain --topLevelPackage com.foo.sample
        module focus --moduleName ~
        module create --moduleName myapp-presentation --topLevelPackage com.foo.sample --packaging war
        module focus --moduleName myapp-domain
        

        Another simple example of a command alias definition:

        <config command="cd">
        	<action type="focusmodule" module="${*}"/>
        </config>

        Shell:

        cd mywebapp-domain

        log.roo:

        module focus --moduleName mywebapp-domain

        These usages do not provide the comforts of command completion on the shell, of course. But it gives a hint of what kind of addon-development-free user customizations the Tailor addon could enable with a powerful enough set of parameterized Actions.

        Show
        Vladimir Tihomirov added a comment - This approach can even be used to define command aliases or command extensions, as long as there are Actions available that support what the user wants to do with that command. Let’s say a user wants to optionally specify the names of the domain and web modules every time he executes the project command. He wants to use arguments like "- domainName" and " -webName", both of which are not valid arguments for the existing "project" command. Without having to change anything in Roo’s implementation, he can do that with a tailor configuration like this: <config command= "project" > <action type= "defaultvalue" argument= "packaging" value= "pom" /> <action type= "defaultvalue" argument= "domainName" value= "${projectName}-domain" /> <action type= "defaultvalue" argument= "webName" value= "${projectName}-web" /> <action type= "executeself" without= "domainName,webName" /> <action type= "executecommand" command= "module create --moduleName ${domainName} --topLevelPackage ${topLevelPackage}" /> <action type= "focusmodule" module= "~" /> <action type= "executecommand" command= "module create --moduleName ${webName} --topLevelPackage ${topLevelPackage} --packaging war" /> </config> The option for the executeself action without="domainName,webName" makes sure that the Tailor removes these options from the original command before it is sent back to the Roo shell. So the shell does not even notice that there were “invalid” arguments for the project command, but the other actions in the Tailor configuration evaluated them to do the command transformation ($ {domainName} , $ {webName} ). Shell: project --topLevelPackage com.foo.sample --projectName myapp --webName myapp-presentation >> log.roo: project --topLevelPackage com.foo.sample --projectName mywebapp --packaging pom module create --moduleName myapp-domain --topLevelPackage com.foo.sample module focus --moduleName ~ module create --moduleName myapp-presentation --topLevelPackage com.foo.sample --packaging war module focus --moduleName myapp-domain Another simple example of a command alias definition: <config command= "cd" > <action type= "focusmodule" module= "${*}" /> </config> Shell: cd mywebapp-domain log.roo: module focus --moduleName mywebapp-domain These usages do not provide the comforts of command completion on the shell, of course. But it gives a hint of what kind of addon-development-free user customizations the Tailor addon could enable with a powerful enough set of parameterized Actions.
        Hide
        Birgitta Boeckeler added a comment -

        I created a forum entry to discuss this and get feedback for the idea:
        http://forum.springsource.org/showthread.php?120190-User-specific-parameterized-scripts-for-common-Roo-tasks

        Show
        Birgitta Boeckeler added a comment - I created a forum entry to discuss this and get feedback for the idea: http://forum.springsource.org/showthread.php?120190-User-specific-parameterized-scripts-for-common-Roo-tasks
        Hide
        Alan Stewart added a comment -

        Initial commit of patched code in Git ID 59bc4df2e8af209b04f4dadec8860b99926c420e. This was committed early as we are about to format the code with an eclipse formatting template using the maven-java-formatter-plugin.

        This feature will most likely be released in 1.3.0, which will be soon after 1.2.1 or 1.2.2, based on our change to release 'minor' releases (eg, 1.3, 1.4 etc) much quicker than in the past. Until the 1.3 release, I have commented out the new commands, however, the code should be reviewed now and any changes can be proposed on this ticket.

        Show
        Alan Stewart added a comment - Initial commit of patched code in Git ID 59bc4df2e8af209b04f4dadec8860b99926c420e. This was committed early as we are about to format the code with an eclipse formatting template using the maven-java-formatter-plugin. This feature will most likely be released in 1.3.0, which will be soon after 1.2.1 or 1.2.2, based on our change to release 'minor' releases (eg, 1.3, 1.4 etc) much quicker than in the past. Until the 1.3 release, I have commented out the new commands, however, the code should be reviewed now and any changes can be proposed on this ticket.
        Hide
        Vladimir Tihomirov added a comment -

        The committed code has been reviewed and tested, it works fine.

        Show
        Vladimir Tihomirov added a comment - The committed code has been reviewed and tested, it works fine.

          People

          • Assignee:
            Alan Stewart
            Reporter:
            Vladimir Tihomirov
          • Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: