Announcement Announcement Module
Collapse
No announcement yet.
Roo First Thoughts and Suggestions Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Roo First Thoughts and Suggestions

    I just ran through a quick walkthrough of Roo after hearing about it at Rod's talk yesterday on the Hyperic acquisition. Roo seems very compelling and can't wait to see what turns out for the GA release.

    Here are some quick thoughts:

    1. I hope that Roo will consider using a templating technology like Facelets for JSF or Sitemesh in Grails to create/compose pages. I really don't want to go back to the old way of coding JSPs. To that end, I hope you can choose your Web framework (JSF, Struts2, Spring MVC, etc.), like AppFuse, to leverage your staff's particular expertise to extend what Roo starts.
    2. I hope there will be SWF integration which will provide OTS support for workflow and Web 2.0 capabilities using Ajax4JSF. Also, the same with Spring Security and Integration.
    3. I wonder how easy it will be to maintain several .aj files per entity. When I first created my entities I was surprised by the number of aspects and I'm not sure if that would be too foreboding to the uninitiated. Nonetheless, I really like the approach to that end, instead of traditional code generation!
    4. Finally, I hope there will be an easy way to augment Roo scripts to generate the Maven POM and other artifacts based on your own environment/standards. We have our own repository and parent poms, so it will be ideal to just extend Roo to generate the POM based on those instead. This is just an example of the types of extension we might do.

    Anyway...great stuff and I look forward to hearing and seeing more!

    Lou

    p.s. BTW, what's SpringSource's driver behind Roo when they acquired Grails? It seems to be a conflict of interests.
    Last edited by Loumeister; May 21st, 2009, 07:22 PM.

  • #2
    Lou

    Good to hear the webinar stimulated you to download Roo!

    I'll let the team reply to your other points in more detail, but the motivation for having Roo as well as Grails is that we want to bring improved productivity to all developers working on the JVM. Grails is a great option, but we must also consider those developers who prefer to (or need to) work in Java.

    We are deeply committed to both Grails and Roo and you'll see significant investments in both (such as Eclipse tooling for Grails).

    Rgds
    Rod

    Comment


    • #3
      Thanks for trying out Roo, and your suggestions. I see Rod already addressed your question about Grails, so I'll respond to the remainder below.

      1. I hope that Roo will consider using a templating technology like Facelets for JSF or Sitemesh in Grails to create/compose pages. I really don't want to go back to the old way of coding JSPs. To that end, I hope you can choose your Web framework (JSF, Struts2, Spring MVC, etc.), like AppFuse, to leverage your staff's particular expertise to extend what Roo starts.
      Let me start by reassuring you that I am not a great fan of JSP. It's noteworthy that developers are supposed to use JSP solely as a template technology, yet as a template technology is limited in that (a) it needs a compiler to run; (b) it will only execute in the web tier and even then in a very specific request dispatcher lifecycle; (c) to write an extension point (taglib) you must be a programmer as opposed to a template author; (d) it allows people to write Java code in the JSP which is unsafe and complicated (you wouldn't normally let a business user do it) and breaks the purported model we are supposed to use (where programming logic shouldn't be put into a template).

      Personally I prefer safe, expressive, easy-to-use, flexible, open source and powerful alternatives to JSP like FreeMarker and Velocity. Yet we live in a world where JSPs are extremely popular and the number of tag libraries makes it difficult for most projects to abandon. Java programmers therefore usually have experience with JSP and expect to be able to use them. As such Roo takes the pragmatic position and supports JSP, as that's what most people want.

      Given the position we adopted toward JSP was motivated through pragmatism alone, we did ensure that Roo carefully decoupled its use of JSP so that we could allow people to use alternative view technologies that are already supported by Spring MVC (such as FreeMarker). If you look at the source tree for Roo you'll see the JSP view generation add-on can be replaced by something else. This was done not only to support non-JSP view technologies, but also those who want to heavily modify the way that JSPs are managed.

      Given we have our hands full preparing other capabilities for release 1.0.0, we don't have any plans to support non-JSP template engines for 1.0.0. A number of other people have also asked about JSF support, and we will take this into account as we plan future view technology support.

      In relation to support of other web frameworks (as opposed to view technologies), our priority when assessing Roo technologies is to what extent they fulfill the Roo mission of fundamentally and sustainably improving Java developer productivity. Because productivity extends beyond pure technology capability, sometimes you need to make an allowance for the popularity of a particular solution even though it might not be the best possible engineering approach (eg JSP). In the case of people who need a server-side web framework, we definitely do not believe this allowance is necessary. We believe the Spring web technologies (MVC and Web Flow) are the very best technologies available for their respective purposes, plus they are highly popular as well. Therefore we don't intend to support other server-side web frameworks. Naturally given Roo is open source the community is welcome to maintain their own add-ons for other web stacks if they believe it desirable. However, I think you'd find most of the motivation would be around view technologies anyway (eg JSF, SiteMesh etc), which as discussed above have already been carefully decoupled so you can do this without losing the benefits of the Spring web frameworks.

      I should note we do intend in the future to support next-generation web application frameworks that operate on the client side. Spring already has support for technologies like Flex, and you can expect to see Roo support for such technologies in the future.

      2. I hope there will be SWF integration which will provide OTS support for workflow and Web 2.0 capabilities using Ajax4JSF. Also, the same with Spring Security and Integration.
      In Roo 1.0.0.M1 we have already added basic installation support for Spring Web Flow. We will supplement that with flow definition support in due course, probably initially using JSPs as the view technology for the reasons noted earlier.

      In Roo 1.0.0.A1 we shipped initial support for Spring Security. This was demonstrated at the SpringOne conference during the keynote "voting application" demonstration. We have a detailed road map for security integration improvement and I'm itching to work on it (my history as founder of Spring Security means I have a lot of personal interest in working on this particular add-on!).

      We do not presently have Spring Integration support in Roo. We have every intention of adding this support in the short term, as Spring Integration is an excellent Spring project and we're very keen to offer it.

      As an aside, one of the benefits of the Roo approach is you can always install something "by hand", and Roo will still work. You can also use the preliminary support for technologies like Spring Web Flow and still customize or write flows "by hand". Roo is not going to be able to write an entire application for people, so we spent a lot of time thinking about the best model that wouldn't get in peoples' way and still let them write code or create files using whatever techniques were most natural for them.

      3. I wonder how easy it will be to maintain several .aj files per entity. When I first created my entities I was surprised by the number of aspects and I'm not sure if that would be too foreboding to the uninitiated. Nonetheless, I really like the approach to that end, instead of traditional code generation!
      Yes, it is certainly a different approach to traditional code generation. We believe Roo is the first generator which emits ITDs/mixins, and particularly one that uses a metadata model to automatically maintain them throughout the development lifecycle. Most other generators bulk output code into your Java compilation units (for you to then maintain and de-clutter) or do lots of work at build time and rely on OO or framework techniques so that the generated code is somehow used. Roo simply uses the compiler to mix its generated code into the compiled class, which gives you the same benefits as if you wrote the code yourself but without having to actually do so.

      Our expectation is the *_Roo_*.aj files will generally be hidden by a user's IDE. STS does this by default. Naturally you can unhide them if you want to, but we see little reason users would want to go into those files except if they were debugging or just learning about Roo. After all, these files are created, maintained and deleted automatically by Roo. If you delete one or change one, Roo will fix it up automatically for you. In the debugging case, the files open up in your debugger automatically - just as you'd expect.

      We acknowledge there are a number of ITD files per target compilation class, but this offers some useful separation of concerns. Take the "toString" add-on, which emits a GovernorName_Roo_ToString.aj file. If we decide a better way to perform toString operations in the next version of Roo, when you run that new version Roo will automatically update these GovernorName_Roo_ToString files. If we put all the ITD members into a single ITD file, we would need a way of identifying which member belonged to which add-on. There are ways of doing so, but they start to become less conceptually rigorous when you consider issues such as identifying which add-on added a specific parameter annotation to a specific method. You have to do things like maintain separate metadata files, which is not a current requirement of Roo (there is no Roo-specific metadata/config file in a Roo application, which we've worked hard to maintain).

      4. Finally, I hope there will be an easy way to augment Roo scripts to generate the Maven POM and other artifacts based on your own environment/standards. We have our own repository and parent poms, so it will be ideal to just extend Roo to generate the POM based on those instead. This is just an example of the types of extension we might do.
      Absolutely. I have received this feedback before and often developers have internal repositories of allowed Maven artifacts etc they wish to use. If you wish to log a Jira issue at http://jira.springsource.org/browse/ROO with an expanded list of your requirements we'd be very happy to look into how this might be best achieved.

      Comment


      • #4
        I was working on an addon to add support for sitemesh using "install sitemesh".
        It adds the dependency to the pom and also creates the decorator.xml, sitemesh.xml and a main.jsp as starting point.

        If you are interested I can share the code.

        Comment


        • #5
          Thanks for the very informative response. It's great to have a better understand and insight to what's planned. I just demoed it to my boss this morning and he seemed to like it, but as expected, he wanted to see a GA release first. Do you have any expectation of when that would be?

          I'll continue to monitor and look forward to yet another successful Spring project!

          Lou

          Comment


          • #6
            Originally posted by marceloverdijk View Post
            I was working on an addon to add support for sitemesh using "install sitemesh".
            It adds the dependency to the pom and also creates the decorator.xml, sitemesh.xml and a main.jsp as starting point.

            If you are interested I can share the code.
            Fantastic! We very much welcome community participation in the Roo project. BTW I really like SiteMesh. I remember writing a SiteMesh extension for Spring way back in May 2004 (http://osdir.com/ml/web.sitemesh.gen.../msg00035.html)!

            In relation to contributions, we're just working through finalizing a few formalities to keep the code clear of any copyright/patent issues. In the meantime if you would like to log a ticket at http://jira.springframework.org/browse/ROO with your SiteMesh proposal, it will provide a single point people looking for Sitemesh services can watch, vote on, provide code at etc. I'll then get in touch with you as soon as we have the formalities completed so we can accept the code. Jira is the best mechanism to ensure we can keep a handle on this. You're welcome to just log the ticket and not upload any code for now; the tracking alone is useful.

            Comment


            • #7
              Originally posted by Loumeister View Post
              I just demoed it to my boss this morning and he seemed to like it, but as expected, he wanted to see a GA release first. Do you have any expectation of when that would be?

              I'll continue to monitor and look forward to yet another successful Spring project!
              We're aiming to release a RC around mid-June and GA around late-July 2009. We will then follow it up with a 1.0.1 release about a month later. Naturally these dates may change a little and cannot be guaranteed, but we're quietly confident they'll be reached.

              Don't forget any feedback we receive (bug reports, suggestions, experiences, contributions etc) during the milestone and RC phases greatly assist us making GA better for everyone and planning post-1.0.0.GA features. If you get any free time to play around with Roo, those experiences are still very helpful for us to hear about and we very much welcome your comments.

              Comment


              • #8
                Hi Ben,

                I think the plugins support for Spring Roo is really cool. But my only concern is the XML configuration. It would be nice if Spring Roo provides builders to hide the complexities of XML writing in Spring Roo (web.xml, pom.xml, and spring contexts).

                Maybe something like:
                WebXMLBuilder.addFilter(webXml).setName(param).set Class(param)


                Thx.

                Donny

                Comment


                • #9
                  Hi Donny

                  Good idea. I logged a Jira issue so we can keep track of your suggestion:

                  http://jira.springframework.org/browse/ROO-62

                  Comment


                  • #10
                    Its seems good and I hope you will keep it up

                    Comment


                    • #11
                      Its seems good and I hope you will keep it up

                      Comment

                      Working...
                      X