This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Strange error with database reverse engineer and mysqlPage Title Module

Strange error with database reverse engineer and mysql

Mar 7th, 2012, 07:44 PM

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?

Comment

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'"

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.

Comment

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.

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..

Comment

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.

Comment

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.