Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:Dali/Juno/JPAMetadataConversion"
| Line 25: | Line 25: | ||
Karen, thanks for your input! Regarding the second question of you, we will just copy the annotations to the xml without touching the Java sources based on the user's initial request. | Karen, thanks for your input! Regarding the second question of you, we will just copy the annotations to the xml without touching the Java sources based on the user's initial request. | ||
| + | ---- | ||
| + | |||
| + | For scalability I'm a fan of "double list boxes" (or whatever they are called), where the left-hand list contains all the possible selections and the right-hand list contains all the currently selected items. The user can use buttons or double-clicks to move items back and forth. You know what I'm talking about. :-) | ||
| + | |||
| + | --[[User:Brian.vosburgh.oracle.com|Brian.vosburgh.oracle.com]] 17:40, 20 June 2011 (UTC) | ||
Revision as of 13:40, 20 June 2011
Nan, this is looking good so far! Here's my feedback, of course more questions than answers right now:
- Do we want to use the xml-mapping-metadata-complete flag? and exclude-default-mappings flag in eclipselink? or just convert the specified annotations in java? If we use xml-mapping-metadata-complete we will need to use the access flag in the orm.xml where it is only denoted by annotation location in java.
- Is the feature to copy the annotations to the xml, or to remove the annotations from java and replace them with orm.xml?
- What about package-info.java files? Generic case doesn't need to support this, maybe adopters have feedback on this one.
- What about JPA annotated binary files?
- If the chosen classes are listed in the persistence.xml they should probably be removed to avoid the Dali warning
- What if a class is already listed in another orm.xml file?
- 'Save as the default mapping file' option. For an eclipselink project would we want it to be the default eclipselink-orm.xml file?
In response to some of your questions:
In prototype 2, if we allow the user to choose classes from multiple projects the orm.xml location needs to be fully qualified. I agree that prototype 2 seems better for its scalability and the fact that it shows the packages.
Would be nice to only show the java resources rather than use a validation message if they choose other resources.
Class level conversion seems reasonable to me, maybe at a later date we could support attribute level conversion.
Instead of 'Excluded from persistence.xml' maybe 'Add to persistence unit' like in the new orm.xml file wizard?
Potentially support merging, overwrite existing entities if they are chosen for conversion and add any new ones that are not already in the orm.xml. I could see this as a future enhancement.
--Karen.moore.oracle.com 16:47, 20 June 2011 (UTC)
Karen, thanks for your input! Regarding the second question of you, we will just copy the annotations to the xml without touching the Java sources based on the user's initial request.
For scalability I'm a fan of "double list boxes" (or whatever they are called), where the left-hand list contains all the possible selections and the right-hand list contains all the currently selected items. The user can use buttons or double-clicks to move items back and forth. You know what I'm talking about. :-)
--Brian.vosburgh.oracle.com 17:40, 20 June 2011 (UTC)