Spring Roo 1.0.0 dev tool released


News: Spring Roo 1.0.0 dev tool released

  1. Spring Roo 1.0.0 dev tool released (12 messages)

    Check out these updated Tutorials for Spring 3 and Hibernate 3.x

    SpringSource announced the general availability (GA) of Spring Roo 1.0.0.

    Spring Roo is described as a next-generation rapid application development tool for Java developers. The vendor says it offers high Java productivity, stock-standard Java APIs, an advanced shell, and more.
    Roo has no runtime portion and does not impose any CPU, RAM or disk storage cost.
    Spring Roo is documented with around 100 pages of detailed documentation shipped with Roo 1.0.0.

    Recommended Books for Learning Spring

    Spring in Action  ~ Craig Walls
    Spring Recipes: A Problem-Solution Approach  ~ Gary Mak
    Professional Java Development with the Spring Framework ~ Rod Johnson PhD
    Pro Java EE Spring Patterns: Best Practices and Design Strategies ~ Dhrubojyoti Kayal

    Threaded Messages (12)

  2. Congratulations on the release Ben and all. I remember the very early stages of the project 3 years ago. It is great to see the final product come to fruition.
  3. Another open source framework that aims to make Java development easier is WaveMaker [disclaimer: I work there ;-)] WaveMaker is a visual development tool that spits out a Dojo/Spring/Hibernate application as a WAR file. Think PowerBuilder for Web/cloud apps. Biggest difference with Roo is that you use a drag and drop visual builder that runs in a browser to create the app (mostly the CRUD functionality) then drop into Eclipse/your favorite IDE to add custom server-side functionality. WaveMaker is open source under the Apache license. More info at: http://www.wavemaker.com
  4. Can someone compare/provide insight about how this compares with AppFuse. I used AppFuse years ago and it seems, based on first impression, that Roo has very similar scope.
  5. Appfuse vs Roo[ Go to top ]

    I use Appfuse for a project and played around with Roo. The biggest difference in my mind is the fact that Roo generates project specific code that uses Aspects to decorate generic functionality whereas Appfuse uses generalized base classes to provide a lot of the basic functionality (GenericManager, GenericDao). Both create very limited CRUD GUIs that are not production useable. I expect this will change over time in Roo whereas Appfuse does not have a design goal here. Appfuse is an encompassing scaffolding product based on a lot of practical experience. It provides: webservices, security, etc. Roo is a roundtrip code generator And obviously, Appfuse supports several MVC frameworks whereas Roo focuses on "just" Spring.
  6. Re: Appfuse vs Roo[ Go to top ]

    AppFuse aims to provide a single initial scaffold of your new project. This is similar to Maven archetypes or Eclipse's "new project" features in that you run them once at the start of a new project and then you maintain the scaffolded code going forward. The scaffold system has no further involvement in your project once you've run it once. Roo, on the other hand, provides a round-trip aware active code generator for your long-term usage on a given project. As such Roo offers value both at initial creation time as well as whenever you are modifying the project going forward. In practical terms this means as you evolve your project, Roo will automatically maintain certain files. To take a simple example, when you add (or remove) a field, Roo will update the toString, getters/setters, JSP pages etc for you automatically. It also offers commands so you can add new capabilities later. So if you need to add security six months after you created the project, you just "security setup". Or if you need to send emails, you just "email sender setup". There are similar commands for many other capability areas well, such as Spring Web Flow, JUnit, Selenium, common JPA providers etc. You just defer the decision as long as you like, and Roo will only add those capabilities at the time you ask for them (and it will also automatically use those new capabilities in your project). There are many other differences as well. Roo allows extension via user-developed add-ons, it offers a highly usable shell, it allows you to incrementally build a new project and add features only when required, it extensively supports the latest versions of the major Spring technologies, it comes with a SpringSource-developed (and therefore endorsed) application architecture and so on. A read of the Roo Reference Guide's Introduction Chapter or simply completing the ten minute test project will illustrate they are very different in approach. Cheers Ben Alex Project Lead, Spring Roo
  7. Re: Appfuse vs Roo[ Go to top ]

    Ben i'm not an expert in Roo but as far as i understood from Rod presentation there would Roo should have better performance characteristics. Grails uses reflection to generate wrapper classes where Roo uses aspects that are generated at compile time and therefore should expose less runtime overhead and would fit more natively into my existing Java environment. Is that an accurate assumption?
  8. You are correct[ Go to top ]

    Roo utilises AspectJ in what appears to be a standard way. This priovides all the benefits that you would expect from this: - Precompile - Support for AspectJ from IDE plugins - Inline the aspect code to safely remove roo - etc Comparisons with appfuse will fall short as roo is (mostly) a super set of the functionality appfuse. It is a superset certainly if you consider the DIRECTION of the project, rather than just what is available as of version 1.0. I ran through creating a test application. Very impressed. Maven integration was very nice. I would suggest going to the effort of downloading the special eclipse dist designed for roo. Nice integration and project overview and you can just delete the whole thing in one hit if you don't want to use it.
  9. I just watched the 10 minute video (building Pizza web app) from the Roo website, and can't see any substantial difference between it and Grails which also runs on top of Spring + Hibernate. Granted Roo's scaffolding Web interface looks a bit more polished in some areas, but scaffolding web pages are always replaced in any real project anyway. It feels like there is a lot more typing in Roo to create a single Domain + Controller + scaffolding compared to Grails. I think I'll stick to the more mature Grails for rapidly developing a web app that runs on Tomcat/Jetty.
  10. There is a recent community-answered StackOverflow thread that outlines some of the differences between Roo and Grails. Regarding your observation about the amount of typing required in Roo, it's actually not too bad. I've presented below a valid Roo 1.0.0 script that will create a custom JPA web project. The whole script is 86 characters, but due to tab completion you would be able to avoid typing most of it (saving at least 50 keystrokes that way): pr x pe s --provider HIBERNATE --database HYPERSONIC_IN_MEMORY en --class ~Kbd fi st cmt co all --package ~ Our samples don't show this sort of usage because we want them to be readable to help people learn Roo, plus with tab completion nobody types the entire command anyway. But if typing is a concern, Roo certainly doesn't require it through shell features like tab completion, command hiding, contextual awareness and command abbreviation. Cheers Ben Alex Project Lead, Spring Roo
  11. I think Roo is terrible[ Go to top ]

    I tried it a while ago and ran into all kinds of issues. Every controller generates 4 pages (edit/detail/list/delete). Editing/ customizing these pages were always overwitten whenever the roo shell is executed. I just moved to Django after that and never looked back
  12. Did you RTM?[ Go to top ]

    You can tell Roo not to mess with your modified JSPs by setting @RooWebScaffold(automaticallyMaintainView=false) in the relevant controller, as explained here: http://static.springsource.org/spring-roo/reference/html/beginning.html#d4e555
  13. Yes I did[ Go to top ]

    I did try that too and did not like it one bit. If for any reason my model is tweaked in the future for any reason, reconciling that change to the view becomes a nightmare. Like I said earlier, I just tried Django with the same Data model and my first impression was 'Wow! now THIS is a framework!'