Gave it a shot - Pluses and Minuses

Quote:

Guys, I applaud the work on Roo. I think in some cases, it will be the default choice for me on projects. Unfortunately I find on my current project I'm only able to use it as a one-way one-time passive code generator. The issues that blocked me are as follows. Just wanted to let you know.

Thank you for the feedback. We appreciate all feedback - whether it compliments or suggestions - and try to respond to it.

Quote:

I am using OpenXava on this project for basic database CRUD. I suppose I could have written a Roo plugin to reverse the database, but it would've taken more time than I had to commit to it, and would have taken a VERY long time to be as rich as OpenXava.

Reverse generation of an existing database is a key priority. I have made a section in the reference guide about this, as I know many people would like to do it. I also sent an email to Rod Johnson yesterday with some ideas on this regard. Would you mind logging an enhancement request about this at https://jira.springsource.org/browse/ROO as it allows us to collect requirements and ideas? I'm particularly interested in which database you're using and to what extent you have special requirements like foreign keys, DB checks, constraints, usage of views instead of tables etc.

Quote:

For whatever reason, OpenXava in it's reflection to gather model information and generate screens, is not obtaining the proper bytecode. AspectJ should be weaving a concrete class in the bytecode from the various annotations, but for some reason OpenXava cannot see the getters and setters. Sadly I don't have time to figure out why that is, but it's most certainly on them, and not on Roo. Still, I am stuck with that particular tool choice, which makes Roo a no-go on this one.

So - I had to punt, after spending a few long days trying to make them play nice together, getting the aspectj runtime jar into the deployment and trying to analyze what was happening.

I do agree this would more likely be an issue in OpenXava. AspectJ's methods are clearly visible (you can see this yourself by using the javap command on a woven .class file) and are therefore reflectively available to OpenXava.

Quote:

So in punting, I still decided to adopt the "rich domain" approach of Roo to the model (over objections, of course - people are so stuck on their dao pattern). So I want to continue to use it for 'first draft' model objects, and push-in refactor.

Ah, the old DAO debate. There's an issue for this (https://jira.springsource.org/browse/ROO-301) but I still remain unconvinced at an engineering level it makes sense. If I add it, it's only because people so frequently want it (not because I think there's even a single good engineering reason for it). Anyhow, ROO-301 exists so there's somewhere all the reasons for doing this can be collated and those interested can watch the issue and/or vote for it.

Quote:

Well there's an issue there too. The push-in refactoring doesn't quite work right yet. Here's the specific items I've encountered that require me to go in and hand edit every single java file. A tedious endeavor.

It's our expectation push-in refactor work in full today. FYI http://jira.springframework.org/browse/ROO-222 is an issue requesting push-in refactor from the Roo shell itself, as we really like the idea of push-in refactor being available to Roo users.

Quote:

* @Roo* annotations are retained and should be removed.

If you take a look at the Roo reference guide that is included in Roo 1.0.0.RC3 and above, I describe the removal procedure. It is a known requirement (step 2 in the docs) to do a global find and replace to remove the annotations. I give the regular expression to use in the docs, so you can do this straight from within Eclipse/STS with success. A related issue is http://jira.springframework.org/browse/ROO-330 to add this capability to the Roo shell itself.

Quote:

* Casing in attribute overrides are not respected. For example, @RooEntity(identifierColumn = "FOO_ID") is built back into the java sources as @Column(name = "foo_id")

I tried to reproduce this but was unable to. Specifically, I used @RooEntity(identifierColumn="My_IdeNTiFier") in my .java source and Roo correctly emitted the following ITD fragment:

Code:

@Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "My_IdeNTiFier") private Long Vote.id;

If you could log a bug report at http://jira.springframework.org/browse/ROO with the steps to reproduce this it would be appreciated. As shown, Roo is emitting the correct ITDs so this may well be an issue in AJDT (which is the software that is actually undertaking the push-in refactor). Still, I don't think AJDT would be modifying the case sensitivity of any string annotation attribute values either...

Quote:

Also I think identifier-name should be a property to @RooEntity. Perhaps my column IS named FOO_ID, but I still want the model class property to be ID. In addition, inheritance-wise, how are attribute overrides supported when retaining the @Roo* annotations?

The identifier name property is actually a property on @RooEntity. I extended the above example to use @RooEntity(identifierField="IDENTITYME", identifierColumn="My_IdeNTiFier") and it now became:

Code:

@Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "My_IdeNTiFier") private Long Vote.IDENTITYME;

In fact you can do this directly from the Roo shell. This would work just fine:

Code:

roo> entity --name ~HelloWorld --identifierColumn MY_CoLuMn --identifierField TheField // outputs in HelloWorld.java: @RooEntity(identifierField = "TheField", identifierColumn = "MY_CoLuMn")

Quote:

Sorry for the meandering post, but I wanted to get all these thoughts down and back to the community before I walk away from Roo on this project.

No worries. Sorry for the long reply! :-)

Quote:

Again - not to diminish - I think Roo is AWESOME, and in any case where it's feasibly, I will use it as at least a starting point. Believe me I know - I was stuck on a few rails projects before...

Once again, we welcome feedback. We do appreciate it. Just looking back over this post it's clear we need to work more on documentation so some of these more exotic @RooEntity options are obvious and the rationale behind "no DAO" is clearer. It would be great if you could log the Jira issues I mentioned above and provide the extra details so we can help make Roo better for the community.

Cheers
Ben