Skip to main content
Jump to: navigation, search


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.
These would be nice options to have, but certainly sound like options. If this ends up as a multi-phase project, perhaps that would be in a second phase. Access type will definitely be something to keep in mind regarding conversion to Mapping files. 19:02, 20 June 2011 (UTC)
  • Is the feature to copy the annotations to the xml, or to remove the annotations from java and replace them with orm.xml?
Base case here is to remove annotations as part of conversion. 19:02, 20 June 2011 (UTC)
  • What about files? Generic case doesn't need to support this, maybe adopters have feedback on this one.
Sounds like phase 2 work. 19:02, 20 June 2011 (UTC)
  • What about JPA annotated binary files?
Maybe it's not necessary to include the annotated binary files into generated mapping files. We could assume they are already well set up in the project and we just refer them in the mappings. 13:52, 29 June 2011 (UTC)
  • 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. 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. 17:01, 20 June 2011 (UTC)

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. :-) 17:40, 20 June 2011 (UTC)

"* 'Save as the default mapping file' option. For an eclipselink project would we want it to be the default eclipselink-orm.xml file?"

I think using orm.xml, but with the eclipselink namespace and schema location would be sufficient. The 'special' eclipselink file is primarily special for use in overriding an existing generic orm.xml, I believe. 17:57, 20 June 2011 (UTC)

Back to the top