Announcement Announcement Module
Collapse
No announcement yet.
Is Roo alive? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is Roo alive?

    Anyone is maintaining Roo? At Jira, the last change was done in 25/Feb/13

    I know Roo is an open source project and Alan is not in VMWare, but the community need a agile way to contribute to Roo, so our pull request should be attended.

    Thanks

  • #2
    I get the feeling we'll have to wait until the Pivotal initiative is sorted out to see what Roo has in store for the future. I agree, I think we should have a way to contribute to the project to move it forward and clarification is needed. +1 on your request for information from VMware on Roo development support today and in future.

    Ken

    Comment


    • #3
      End of an era

      We might be watching the end of an era unfolding...

      Without Rod Johnson, Spring source has become a just-integration-no-innovation shop.

      Without innovation it will really be hard to prevail in a very-very competitive market; specially when your main differentiator -IOC/DI- has been assimilated by your main competitor.


      I hope I am wrong in this one.

      B. Roogards
      jD
      Last edited by delgad9; Apr 2nd, 2013, 05:26 PM.

      Comment


      • #4
        Ken,

        I'd like to get your thoughts on the future of spring/roo. How about a nice blog post? I've built a pretty nice application on spring with roo as a starting point, and extjs as a front end. Roo has helped flatten the learning curve as I've moved from .Net to Java. I think roo it's very close to being an amazing project. It seems to me that there are a few simple things that could be added to make the code-generated user interfaces more useful out of the box. I wish a strong team would get behind one of the UI plugins and create some more impressive demos.

        Comment


        • #5
          Comment appreciated, FreeCoffee.

          Yes, I have plenty of thoughts about where Roo is now and what it could do in the future. Writing a book for two years tends to do that to a person. I have a vested interest (altruism, the book, future royalties) in seeing Roo not die, so I 110% agree with you. I am hopeful that we see an opening up of the project again quickly so it doesn't die due to being out of mind too long. It really has some great parts, especially the shell mixed with a pluggable add-on architecture.

          I'm so busy with wrapping up our Emerging Tech conference this week that I just can't add the blog post. I'll elaborate here since it's probably the best place to get my feedback down.

          Where it currently breaks down for me is the web tier. I feel Grails and Rails got it right - generators are for beginners and getting started, but get it out of my way if I'm writing my own application. Also, make UI parts pluggable, and don't make too many assumptions. I think it was great for a 1.0 project's web app tier, but I almost always gut it and do my own thing. I had suggested this feedback to the team in the middle of writing the book, but I think it was put in the "when we get to the next big version" category.

          JSPX is an unfortunate choice for day-to-day development, and feels quite limiting and full of too much ceremony. I would like to see different page parsers - even using Velocity, HAML or Thymeleaf. Spring is built for that, and most of us honestly don't need the bi-directional 'keep the page in sync with the model' choice. It's nice as a feature, but if it makes development tedious, we'd all probably drop it for a push only get-it-started template in our favorite view language.

          Also, the reliance on Dojo is an artifact of 2008/2009 web programming, and not relevant anymore. We should have the ability to choose the client-side toolkits we want, and to go to a single page web application if we feel we should. AngularJS is my current passion right now, and Roo doesn't easily integrate with it - you have to behead and adjust a lot of things to get it set up. Not that it's a big deal, but it should be thought of going forward.

          The localization templates are a good idea, but the syntax is very long for what it should be - there needs to be a way to flatten it and remove it outright if I never wanted it in the first place or wasn't scaffolding. So bottom line, the web mvc add-on needs to have differing levels, such as:

          web mvc setup // just give me <mvc:annotation-driven /> with some good assumptions, JSON/XML converter support, etc.
          web mvc install-theme
          web mvc install-localization
          web mvc install-client-toolkit --type dojo|yui|etc...
          web mvc install-template-engine --type jsp|jspx|velocity|thymeleaf|haml|etc

          Also, we need a command for push-in refactoring - sewing up and leaving Roo at the door. Using the IDE isn't enough, and many want to use other IDEs for an ultimately non-AspectJ architecture. You can't use IntelliJ right now because the team there hasn't implemented the 'declare parents' feature - which was introduced in Roo 1.2.3 I believe (maybe 1.2.2) so we need to keep bugging them on that score (vote up http://youtrack.jetbrains.com/issue/IDEA-59138). And once pushed in, we should be able to access the app code from NetBeans or other IDEs as well.

          Roo is great for starting up projects, but it would be more useful if we could keep it for those who want it well up into the web tier, without having to resort to hacking it down and working around the current web addon to do so.

          I am hopeful that the dev team adds external committers and helps us establish a way to install add-ons from the internet easily. The big problem is that if nobody sponsors or keeps the add-on repo running, we won't have a place to search for and then add add-ons.

          Further, I'd like to suggest that if Pivotal wants to sponsor Roo development as an open source partnership, but not engage in it as a key activity, they could commit to providing a part-time 'caretaker'. This person could make sure we have server space on AWS, Cloud Foundry or another place for whatever future online resources we need to manage add-ons, and that caretaker could appoint committers who could ultimately be in charge and push builds. Or they could donate it to Apache or Eclipse and see what happens.

          Let's see what ideas Pivotal comes up with. I don't want to see push requests go ignored, and I'd certainly be more inclined to help with the development now that the book is over, if I knew we were on a path to having releases that we need to keeping Roo moving forward.

          I hope this feedback is taken in a positive light, and helps VMware/Pivotal.

          Comment


          • #6
            Have any times scales been announced for pivotal decisions to be communicated?

            Comment


            • #7
              Count me as a Spring Roo fan who just cut his teeth on his first successful Roo contribution ( see https://jira.springsource.org/browse/ROO-3376 ).

              I tried my best to document things as I went along as comments to the above Jira in hopes of helping others who might also be interested in contributing. In my case, I am hardly a noob, as I have been coding since cavemen were still painting on cave walls, but this was my first Spring project contribution, as well as being my first git pull request, so in this sense, it was a true learning experience for me and I imagine it might also help others as well. Chances are, there really needs to be a readme which is more specific to unofficial contributors like myself, as the readme which comes included in the Roo source is really geared more to the official contributors. To be honest, I am still a little unsure what to call my contribution, as well as the carefully crafted analysis done by Roger Villars and others, without whom my contribution would probably still be stuck at square one. Ken, feel free to use any of my Jira notes in your book if you like.

              As for wish list items, I too have been looking into getting more rich (browser) client focussed as this is where the web seems to be heading. AngularJS appears to be gaining in popularity, but there are a plethora of different javascript packages out there these days. Take a look at the many different JS framework options in Netbeans for example. One of the other Javascript packages which seems to be getting a fair amount of traction in the Spring community is Cujo - which I think complements Angular - but I have yet to really cut my teeth in any of these newer JS packages. In addition to REST, another couple of hot buttons for me are three.js for 3d, and JWebsockets for light weight communication protocol to the front end. I think if Roo could help people scaffold any of these things, then I think it would renew its lease for another few years anyway.

              Dave McLure

              Comment

              Working...
              X