Strange error with database reverse engineer and mysql

I was able to use the dbre with roo 1.1.5 and 1.2.0.M1 however when I try 1.2.0.RELEASE, 1.2.1.RELEASE it always fails with the the following error message (I removed the package name):
Compilation unit package '*' unexpected for type 'java.lang'

This is the command that I used:
database reverse engineer --schema no-schema-required --activeRecord false --package ~.database

The annoying part is that it works just fine if I drop back to 1.2.0.M1, it just doesn't work with any newer release. Although to be accurate, even though it runs through the dbre process just fine on 1.2.0.M1 I have to go in and manually modify the dbre.xml to fix an issue with TEXT fields. Could this be the issue creating the mysterious error message?

You can log a Jira issue for us to look at. Please make sure you attach your dbre.xml file and if possible the MySQL schema DDL.
Thanks

Hi team, sorry for my English.
I was working on sts2.7.2 early, today I downloaded 2.9.0 release and have a lot of strange problems.
I can't create any project as before.
database reverse doesn't work with me at all. I'm having same message "Compilation unit package unexpected for type 'java.lang'"

Let me attach project backup and database structure here.Attachment 4768Attachment 4769

Also, if I use project structure (src packages) as 2 level (uz.test), spring roo dowsn't work at all inside STS, but work from console
But if I will use 3 levels (uz.test.testit) - it works both console and STS.

Please take a look, if I have to create JIRA issue, I will do so.

Seems I have too much problems :)
I installed ubuntu 11.10 64bit, openjdk-6 (sun-version is also installed)
And for STS 2.9.0 I have an error "Project facet grails.app has not been defined. It is used in plugin com.springsource.sts.server.tc.core", which prevents project creation.

Can anybody explain, how I can upgrade STS to 2.9.1M2 version?

and one more thing,
on STS 2.7.2, roo console - database reverse doesn't do anything, but if I run roo from console - it successfully created all files!

I don't want to create a new thread, so let me continue posting here :)

Here is another thing I found, it related with ROO 1.2.1 version:
ROO generates a database table class and some aspect files. By default it generates for ID column code in *_Roo_Jpa_Entity.aj like

Code:

---

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

---

If I move this code to the class file (just to change GenerationType.AUTO to GenerationType.IDENTITY), Roo:
1. removes this annotations only from original *_Roo_Jpa_Entity.aj
2. creates *_Roo_JavaBean.aj and writes there getId() and setId() methods

But, both methods still exists in *_Roo_Jpa_Entity.aj! So we have an error. To fix it I have to move both methods to the class, where an annotation has been moved.

And if I later edit entity class file and remove from there getId() and setId() methods, Roo adds boths methods to *_Roo_Jpa_Entity.aj and also creates *_Roo_JavaBean.aj. SO no way just to move annotation, I have to move methods too.

In Roo 1.1.5 version of STS 2.7.2 this problem didn't exists. Think it is an issue too..

I just throught I would post back that I found what was causing the error for me. The difficult part is that I can't directly fix it.

Basically what was happening is that I had a table called Thread. This is a violation of the rule with java.lang and hence the error. However this is an existing database created before Roo existed. So in a way I feel disappointed that Roo doesn't give it an alternate name to ensure that it doesn't error like this.

So currently the solution is to do this, if you run into this problem:
1) build it with 1.2.0.M1 so that you get the latest database reverse engineering setup (ie the change in roo's entity name).
2) Then rename the class that breaks the ability for Roo 1.2.1 to work with.
3) Load it up in the Roo 1.2.1 and watch it go to work for you again.

Annoying. Anyways enjoy.

If you can't change the table name, you can modify the dbre.xml file to change the table. However, this can potentially affect future reverse engineer operations.
Alan

Quote:

---

Originally Posted by Alan Stewart

If you can't change the table name, you can modify the dbre.xml file to change the table. However, this can potentially affect future reverse engineer operations.
Alan

---

I noticed that you could create a class and annotate it with the table name and it would do the reverse engineering without issue as well. Not entirely sure this is intended behavior, but thought I should point it out. It does at least allow me to reverse engineer as many times as I want after that without breaking.

Correct - sorry, forgot to mention this feature. Mapping table names to entities can't be changed on the database reverse engineer command, but user changes afterwards are respected and maintained.