Announcement Announcement Module
No announcement yet.
About blueprints and Roo“s scripts Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • About blueprints and Roo“s scripts

    Hi people,

    Disclaimer: This is a sort of stupid post to discuss some stupid ideas, probably without any practical issue

    After reading this post where rohitpant asks if Roo could record manual work done on Roo“s projects i remembered an Adrian Colyer post in SpringSource Team Blog ( where he speaks about Bluprints power.

    That take me to think that Roo“s scripts are indeed a sort of blueprint of applications, truly this blueprints are limited because they use some conventions (you use spring, maven, jpa a rich data model, etc) to reduce the amount of information needed to define an entire application. If i simply could find a way to add manual modifications information to Roo“s script I could simply replace all of my subversion code with a Roo“s script or send an entire, functional out of the box, applicattion to my boss via email.

    What do you think of this idea? Do you see some value on it or do you think is something stupid? Of course to achieve this the "manual work information" must be reduced to the same ratio the "generated code information" is using, i don“t need a 200 kb metadata file to tell me there“s is a new custom class in my Roo application.

    Roo uses a pretty complete metadata model to gather information about the application it“s managing. Could it be possible to use this metadata model to gather the information of manual changes in a feasible manner? After that, could it be possible to express this changes in a reduced, conventions based, way like the one Roo scripts use? And after all, could it be possible to make Roo understand this new metadata and so been able to generate fully customized applications out of the box?.

    Of course, when i speak about defining applications i speak about not any type of applications, but that applications following the conventions, in this case, using spring with a rich datamodel, using rest controllers, and so on, nothing about other type of applications.

    What do you people think??
    Regards, Raśl

  • #2
    When I implemented I was aware the next logical thing people would want is the ability for script recording to somehow reflect manual changes made to the project.

    The main problem is the script recording in ROO-274 is very basic. The user can edit the script file or delete it at any time. If they do that, we lose the record of what the user did.

    The simplest pragmatic solution would be to assume ROO-274 is not tampered with or removed and then add a new "build script" style command. That would make a temporary directory, run the script recorded courtesy of ROO-274, then perform a file system diff between the original project and the new project. The diff would then be stored in a file that could separately be applied via another command. The combination of the script and the diff file would then be sufficient to create the project, although binary resources would also need special consideration.

    The more extensive solution would be to discard the ROO-274 log. A project introspection command could be developed that would look at key outputs of Roo, such as the persistence configuration or application context. It would then build a script file via introspection of the existing project. The existing metadata model is adequate to allow most entity, field and controller scaffold type operations to be detected. The aforementioned diff model could then be used with the introspected Roo script.

    While technically feasible and no doubt of interest to people, the truth is that ROO-274 coupled with the backup command will address 80% of use cases that require the ability to rebuild a project again. The good news is these features do not require any changes to Roo core or internals and could easily be implemented via a third party Roo add-on. I'm not sure if the Roo team would be able to work on something like this while we have major feature areas like DB reverse engineering, richer/simpler MVC, GWT, Flex, cloud deployment, noSQL DBs etc that people are really keen on having. It can always go into Jira as a feature idea, though, and hopefully people who would like it will vote on it or collaborate/contribute their first implementations against the Jira issue.