End-to-end Development in ROO

All,
I am sure this question has been asked before, but I couldn't quite find the answer I was looking for. So, I apologize in advance.

I am beginning a brand new project, and ROO seems to be a great fit for it. From what I can see, the entire project lifecycle should be manageable by using ROO, i.e, prototyping and development from scratch, to deployment and continued enhancements.

My question is this - are there large scale projects out there that use ROO all the way from initial prototyping to actual deployment, and ongoing enhancements?

Many thanks,
Prashanth Nandavanam

Prashanth,

Not sure if that is what you mean my large scale, but since no one else has offered an opinion yet I will give you mine. My current Roo project has 80 tables, there are 2 developers developing and maintaining over 12 months.

These are my personal "tips":

- Break the project up using modules - STS Eclipse runs slowly when you have everything in one. It also helps development by separating concerns. You have to run security el at plugin for each module.
- The DBRE function is great for managing 80 plus tables. But we cant get it to work module by module so have a commons module with DBRE --includeTables "*"
- Do not use Roo within STS - use it from within a shell and then synch the files in STS. If I had to guess what causes the resulting corruptions I would say Eclipse file buffering problems.
- The Roo scripts are where to keep the intellectual property about the development. We have one for each module. That way you can re-generate a module either because of a corruption of the module or to generate into another context.
- To facilitate this keep hand written code as separate from the Roo generated code as possible. We use Aspects to do this, as well as having in the modules scripts "! bash-script" where the bash-script is copy in of files etc
- When you do make changes to Roo generated code we annotate with a special string ("\\ zzz") so you can always find where you made changes. If you do re-generate this will be a massive saving as you can find all your changes easily.
- Do use Repositories and do not use Active Record, as it's not ideal when you need a service interface that has a transaction involving multiple entities. And it is inevitable that as the app grows in sophistication, you will need to do just that. (I got this from jhall at http://www.manning-sandbox.com/threa...51580&tstart=0, and I agree

If you or anyone has contra tips or other tips it would be great to hear them.

Greg,
Many thanks for your thoughtful response. I've begun working on my project, having taken into consideration all of your suggestions. It's working out fine so far, but takes some getting used to. I'll add to this thread if I discover anything on my own.

Cheers,
Prashanth

Quote:

---

Originally Posted by greg.soulsby

Prashanth,

- Do not use Roo within STS - use it from within a shell and then synch the files in STS. If I had to guess what causes the resulting corruptions I would say Eclipse file buffering problems.

---

What's the point of Roo if you can't use it inside the IDE? The round-trip code generation is the distinguishing feature of Roo. Without that, it's a glorified templating system. The only other programming environment I've ever used that could keep the high level IDE view and the low-level code in sync, in both directions, is Ab Initio, a very expensive, proprietary ETL product.

If the Roo team were able to iron out these kinks, they would have a real game changer. But it's going to require a real partnership with the Eclipse organization, to achieve that level of tight integration with IDE.

Quote:

---

Originally Posted by brucebaron

What's the point of Roo if you can't use it inside the IDE? .

---

There's actually no functional difference using Roo in the Terminal outside of the IDE than in it. I did that when I started Roo when using Netbeans as main IDE and I've done it from time to time after that too. Of course the commands overview is nice but you can do without it as Roo hints usually are helpful enough.

Inside the IDE the project you work with is mainly a Spring project and as such all resources and possible commands available inside the IDE is just as available as when you're using the Roo view in the IDE. Refactoring and so on. Just keep Roo running in the terminal on the correct project, or if you forget it, run it when you need it.

I've occasionally encountered similar problems with corrupted files as Greg, but I commit for every major operation instead of avoiding Roo in the IDE. This have worked fine for me so I still use the Roo view inside STS.

Spring Roo is an open source Rapid Application Development tool for Java developers. Spring based applications performing CRUD (Create, Read, Update, Delete) on Entities can be easily build using Roo. It is not an IDE or a runtime. It is just a programming methodology combined with a code generation tool. By just providing the entities and their fields, Spring Roo can generate end to end code for all CRUD operations.

This post analyses the applicability of Spring Roo in building enterprise applications where simple CRUD functionality and auto generated screens may not be sufficient.




Checkpoint 156-215.71 Questions & Answers // Testking Cisco 350-001 Pratcice test // Testking CWNA PW0-270 Practice test

Gerry22, What post is that?


Anyway, I also would like to hear about large scale Roo projects that are operative.

In my own projects. not large scale, I've abandoned jspx (but not Tiles) except perhaps for the first phase and implement my own view as I find that more productive. The basic set up including handling of databases, which may shift during development and most or all of the domain model is still built and handled by Roo. I build on all that and maintain a TDD process during development. I, the developer, am in control and not the tool.

I don't view Roo as a CRUD tool, but as a springboard — pardon the pun — to the Spring universe. It's the Spring Framework that is the key to understanding Spring Roo. If one doesn't understand the former one will not be able to fully utilize the power of Spring Roo.