I had the oportunity to evaluate Spring Roo some time ago but I didn't actually use it in a project till recently. Today, after hours and hours of heavy I wanted to share some thoughts about the tool.
First, it has some AWESOME features:
First, it has some AWESOME features:
- There's absolutely no way to create a project from scratch that packs a Spring context, Maven, a security solution, REST/MVC and persistence in less time. Everything is very well configured and just works, in a matter of seconds and four commands. Congrats here to the Roo team.
- The @Configurable entities (ala Grails) are incredibly useful. Having an EntityManager injected in the model and predefined CRUD methods is invaluable.
- The environment. Both, the command line tool and the STS plugin. IDE integration surprised me, it's well rounded.
- As mentioned, Roo is fast when creating a new project. It comes at a price though as your commitment with the Spring stack is absolute. Of course, this may be a non-issue for many people as of today.
- Roo values Convention over Configuration and in such spirit it makes a lot of assumptions..on your behalf. I've found some of them questionable. For example, in a tool so focused on persistence, why is the authentication provider configured in memory by default? Of course, it works out-of-the-box, but I'm pretty sure that 99.99% of the users will change that. Roo creates a login page for me, great but I was expecting a DB authenticator in there (and User and Role classes!)
- Controller scaffolding...yeah. It works and it's fine. It's just that a real application may look like the generated pages...or not. If not, and that seems to be my case all the time, it's not worth the effort. For a rush...a good addition!
- Roo seems to take a reckless approach to programming. It's not what I would call an error friendly tool, not even by a far margin. Not that Roo fails by itself (seems quite robust in fact) but the user will undoubtedly do it. That's not actually an issue, everybody makes errors. The problem is how easily you can fix them. Any IDE basically provides an unlimited UNDO/REDO capability. Fixing something is a matter of pressing CRTL+Z in most cases.
Things are not that easy with Roo, obviously because it lacks the UNDO command, but in more subtle ways aswell. The generated code cannot be touched (it will be overwritten time and again) and pretty much everything is generated (90% of the code is hidden to the user). And even if it could it would be a daunting task unless you're an expert in AspectJ syntax.
Many many times, it's just better to delete the involved source files and restart the work. Do I have to mention how frustrating this can get? May be it's me, I'm so used to it that I don't really pay the due attention anymore but, lo and behold! check twice before clicking that Execute button with Roo
4 comentarios:
I think it's worth pointing out that you seem to misunderstand something about the way that Roo generates code using AspectJ ITDs. The idea is that you can simply implement any method that want in your regular Java code to replace whatever Roo generated in the .aj files. You don't have to touch those files ever (like you say, they will be regenerated if you do), but if Roo finds that you've implemented something yourself it will simply leave your code alone. It's very non-obtrusive that way. To change the generated code instead of replacing a method from scratch, the easiest thing to do is to use the built-in "push-in" refactoring from the AJDT plugin to move the code from the .aj file to your .java file.
If you don't want Roo to generate code for something like JavaBean setters and getters at all, just remove the corresponding @RooXXX annotation from your class. It will immediately remove the .aj files that have the associated getters and setters.
Hope this helps,
Joris Kuipers
Senior Trainer/Consultant working for SpringSource
No...I know that.
But let me put an example. Create an entity with a java.util.Currency field and mark it as @NotNull. Roo will automatically generate tests for it but will set the field as null (it can't create random object instances of the Currency class it seems). The test won't pass, of course. You have two options now, fix the generated test code (bad because it will be overwritten when the entity changes again) or manually create the test method (bad because from that point forward you'll have to include changes by hand when the entity changes).
I would say generating methods by hand is only useful when the business logic asks for it (say...a setPassword method that needs 3DES encryption). Otherwise it really defeats the purpose of a productivity tool. That said, I'm quite happy with code generation in Roo (I'll repeat myself here, it's not for newbies though!).
Jose, thanks for taking the time to provide some feedback on your Spring Roo experience.
We're pleased you found it a useful jump-start and enjoyed the IDE integration and usability experience. In relation to the areas you feel could be improved:
- Sure, it's true that when you use Spring Roo the Spring technologies are used in the resulting project. But that's what someone would probably expect when they used a tool called Spring Roo. :-) We actually consider it a feature that the same people behind Spring have pre-integrated many of the Spring goodies via a tool and ensured those technologies work well together in the default configuration.
- On the default of an in-memory authentication provider for Spring Security, I can personally take responsibility for having coded that add-on. To give a little context, back in 2003 I founded the Acegi Security project and this subsequently became Spring Security. This experience taught me that everyone does something unique when it comes to their security repository. A "hello world" experimenter will want it via an XML file they can edit. A standalone webapp will want it via a database (via JDBC in most cases and sometimes via a JPA/Hibernate model if they use those technologies). An enterprise will want it via LDAP, or SiteMinder, or CAS, or Kerberos, or one of the other dozen common providers. So Roo picking an in-memory XML database is simply conceding the challenge of picking a repository that suits every situation is difficult, as there really isn't one. What we should do though is add more features so you can type "security setup database" for example and it makes that easy etc.
- Controller scaffolding is intended simply for scaffolding a backend admin UI. We don't expect the public-facing part of your app will be the scaffolded controllers, and nor does any other RAD-like tool promote that type of capability. For some apps it works, but most of the time people will use the scaffolded UI as a guide to writing their own custom UI. Using the scaffold ensures the correct configuration of the appropriate web stack (Spring MVC, Spring Web Flow, Google Web Toolkit etc), offers a quick proof of concept, and provides an example of how to use the technology in the user's problem domain.
- Concerning the lack of an undo feature, we do have an addon-git which automatically associates user commands with Git commits and thus simplifies rollback and also determining exactly what Roo changed. But setting that aside, Roo never automatically modifies anything but files it is designated to look after. So it might modify an AspectJ ITD or a scaffolded JSPX, but the vast majority of your user project is never automatically modified by Roo. You can easily change a .java file at any time and watch Roo adjust automatically. This includes "stepping back" from providing a member (eg field, method, constructor etc) if you have provided the equivalent via manual coding. We try to make this as natural as possible so you can just go off and code and forget Roo is providing the remaining capabilities automatically.
- Roo's initial focus was on experienced enterprise Java developers interested in a very high productivity value proposition while using the technology stack they already understood and had approval (and confidence) to use. In more recent times we've found the Roo audience expanding to include a substantial number of people new to Java programming (as well as enterprise Java). As such we are working to more diligently cater to this growing group.
Roo is expanding rapidly, both in terms of community size, features and also the number of full-time engineering resources we have committed to it. As such it will continue to improve. We hope you take another look at Roo in the future and I welcome any feedback you might have. Please feel free to email me at balex at vmware dot com if I can ever be of assistance.
Best regards
Ben Alex
Project Lead, Spring Roo
VMware Inc
Hi Ben, thanks for the polite comment.
Maybe I was misunderstood! I'm quite happy with Roo! I'm still using it and I have no intention of changing that.
I think many of the issues I've found are easily fixable (like extending the security setup like you mentioned or supporting some common classes like Locale or Currency). I think these will be non-issues as Roo matures.
The UNDO feature is another beast. Relying on the SCM is an option but IMHO Roo should provide some mechanism. Just having the option of typing "undo" at the console would be a relief many times.
The only real issue I think Roo will have in the near future is the required skills. I lead many many IT projects around here and I'm sure most (if not all) of my programmers would be overwhelmed by the amount of "magic" happening. Many people say they know Spring but that amounts to defining beans in a configuration file...nothing beyond that.
Publicar un comentario en la entrada