Announcement Announcement Module
No announcement yet.
Why I love Roo more than anyone else Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why I love Roo more than anyone else

    They asked Watson senior how many of his new business machine IBM expected to sell. He answered that the world needed perhaps half a dozen computers.

    So, maybe, because a person invents something does not mean they are equally brilliant at assessing its market?

    I give this as an example: "Roo is marketed as a “next-generation rapid application development tool for Java developers”"

    These are Roo commands that generate a small app:
    project --toplevel package ....
    osgi start ....
    jpa setup --database ....
    database reverse engineer ....
    web mvc scaffold ....
    To me, calling this Roo code a tool for Java developers is to call a car a horseless carriage. It is expressing the thing in the terms of the current mental model, when a new mental model is called for.

    In the development life-cycle we are putting together the developers do not post versions of the application code to Bitbucket. We post Roo scripts, Roo plugins, SQL to build the databases, artefacts from other code generators, Spring config files and snippets of hand coded stuff that Roo at al do not cover (which includes Java code of course). Developers generate the app on their machine, not copy it down. We are targeting a model driven process. The outcome is a Java app, but we do not work much in Java.

    Roo brings dependency injection, aspects and all the things great about Spring to the code generation domain. Roo bests the other code generation tools like Spring bests other enterprise Java approaches.

    To sell Roo to Java developers is to sell Christmas to Turkeys. Roo is an object of love for developer strategists.

    Does anyone agree?

  • #2
    I agree to an extent. I strongly agree that Roo gets mis characterized. I prefer Roo to Ruby on Rails or any of those related technologies. My own wish list about Roo has to do with the same complaints with other open source technologies, namely quality and documentation. This latest 3.1 of STS and Roo 1.2.2 has many problems and I just downloaded this morning.


    • #3
      I'm not sure. Together with another developer on my team I've spent a week now getting to know Roo, to see if we can use it for a new project we are starting.

      It looks useful to get the project up and running, but I'm not sure if it will hinder us further down the road and we'd end up pulling it out.

      Running into really simple problems make me wonder how many people are actually using Roo. For example I started part of the project which needs no persistence, as it's all in memory. But I wanted to make use of @RooJavaBean & @RooToString for the model. It turns out it's impossible to compile this without adding the persistence-api and spring-orm into the project.

      Then I look at the generated toString aspect declaration, and it's using a ReflectionToStringBuilder. Disappointing to say the least. I had expected it to generate a toString that didnt use reflection at run-time (for performance reasons), else what is the point of using aspects?

      Also how do I tell Roo to generate TestNG test code rather than Junit?

      And where are all the addons? I download Roo 1.2.2, and I do an "addon list", and only 9 addons show up. Confused.

      So for me, so far it's a mix of delight in the things that do work and some disappointment.