I do support multiple relationships between two tables (fields are suffixed with an incremented number to avolid clashes) so I am curious to see why any errors are produced. For me to proceed, would you please attach your MySQL DDL so I can attempt to replicate any problem.

Hello,

I'll try to describe how to reproduce this problem and explain the database structure that produces following error message:
Field 'typeGroups' already defined in ITD (ITD target 'roo.issue1902.domain.Type_Roo_DbManaged)'

To reproduce this problem you need to do following:
1) create database structure(I used mysql):
See the attachment ROO-1902_demo.zip/roo_1902-issue-base.sql
(if you have MySqlWorkbench installed, then see the graphic representation of the DB structure from the attachment roo_1902-issue-base.mwb. roo_1902-issue-base.sql is generated by MySqlWorkbench based on this model).

I'll also try to describe DB structure with few sentences for those that don't want to look into attachments:
For the demostration of this problem I created following tables: "type", "type_group", "type_group_has_type"(used only to represent many-to-many relation) and "other".
The key relations between those tables regarding reproducing this problem are following:
type --< type_group
type > - < type_group (in reality modelled with intermediate table: type – < type_group_has_type > – type_group)

2) create roo project using following roo commands:
project --topLevelPackage roo.issue1902 --projectName roo_issue_1902 --java 6
persistence setup --database MYSQL --provider HIBERNATE --userName root --password mySqlRootPass --databaseName roo_1902 --hostName localhost
database reverse engineer --package ~.domain --schema roo_1902

------------------------------------------------

Here are the changes that if made independently would allow DBRE to complete successfully:

1) Removing "other" table (all other tables not related to type and type_group). It doesn't mater if this "other" table was related to rest of the tables or not, problem can be reproduced even if it just exists.

2) If I removed either one-to-many or many-to-many relation and left everything else the same, then also DBRE completes successfully.

However one strange thing that would allow DBRE complete successfully would be to use a number after a dot in the name of the package - unfortunately this is not a valid Java package identifier so that project can't be compiled.
If topLevelPackage is roo.issue.1902 or roo.1902issue or roo.1902issue.test and everything else remains the same based on "base situation" then I managed to complete DBRE (and of course failed on building the project).

Ats

Do you see any stack traces or errors? With the latest Roo code from Git your script completes successfully for me. Would you please try the latest code as there have been substantial changes since 1.1.0.RELEASE.

When you first execute the database reverse engineer command, you will will have to install the MySQL driver, but typing addon install --bundleId 01 ( there will be a help message for you)

While was(and still am) having this problem with 1.1.0.RELEASE this problem didn't occur with development branch. I didn't see any stack traces or errors with 1.1.0, just the UNDO lines and the error message I described.

tnx

I was able to verify that 1.1.0.RELEASE does indeed have this issue, however the problem has been subsequently fixed and will be available in the impending 1.1.1.RELEASE