Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Dali/Juno/JPAMetadataConversion"

< Dali‎ | Juno
m
(Discussion && Question)
Line 81: Line 81:
  
 
'''Note:'''
 
'''Note:'''
*Your feedback about prototypes, use cases, and questions would be appreciated.
+
*Your feedback about the contents are very welcome.
 
*It would be better if you could give your feedback with the format [name:feedback] to facilitate our communication, thanks!
 
*It would be better if you could give your feedback with the format [name:feedback] to facilitate our communication, thanks!
  

Revision as of 16:42, 17 June 2011

Functional Specification: [JPA Metadata Conversion]

bug 138622- Convert annotated JPA metadata to orm.xml

Document History

Date Author Version Description & Notes
Nan Li 06/16/2011 Draft 1 - Add initial prototypes, use cases, and questions we have to collect requirements

Feature overview

The purpose of this feature is to provide the ability to generate mapping files from the annotated sources so that users can get different behaviors by configuring generated mapping files without touching their well configured sources.

Use Cases / Requirements

Prototype Option 1

Prototype Option 1

Use Cases

Use case 1-1
  1. User selects several classes from same or different packages and chooses Metadata Conversion
  2. The selected classes are listed and user can select/deselect the classes he wants to convert
Use case 1-2
  1. User selects several classes from same or different packages and chooses Metadata Conversion
  2. All the valid mapped classes in the selected project are listed with the pre-chosen ones be selected, and user can select/deselect the classes he wants to convert
Use case 2
  1. User selects one or more package(s) and chooses Metadata Conversion
  2. All the valid mapped classes in the selected package(s) are listed and user can select/deselect the classes he wants to convert
Use case 3
  1. User selects a project and chooses Metadata Conversion
  2. All the valid mapped classes in the selected package(s) are listed and user can select/deselect the classes he wants to convert

Prototype Option 2

Prototype Option 2

Use Cases

Use case 1
  1. User selects a class(es)/package(s)/project and chooses Metadata Conversion
  2. The project hierarchy tree shows up with all the available projects and the pre-chosen ones be selected
  3. User can navigate the tree to select the mapped classes he wants to convert
Use case 2
  1. User selects a class(es)/package(s)/project and chooses Metadata Conversion
  2. User selects “Save as the default mapping file” checkbox, the combo box and Browse button will be disabled.
  3. User hits Finish button, the generated mapping file will be saved to META-INF folder named orm.xml.
Use case 3
  1. User selects a class(es)/package(s)/project and chooses Metadata Conversion
  2. User clicks Browse button for specifying mapping file
  3. User select “Excluded from persistence.xml” and hit Finish
  4. The generated mapping file won’t be written to the persistence.xml as a mapping file refer entry.

Discussion && Question

  • Prototype option 2 would work better when lots of Java sources exist in the workspace since it may tiresome for users to select one by one with option 1.
  • With prototype option 2, all the resources in the selected node would be shown in the right side window considering our uses are developers. Validation message should be given when invalid conversion resources are selected. Should we prevent invalid resources from being shown up?
  • We assume users would want to convert all the metadata in a Java source so we only give the option to choose classes. Do we want to provide the ability to let users choose which attribute mappings they want to convert?
  • By default the generated mapping file would be automatically included in the persistence.xml since mapping files except the default ones (META-INF/orm.xml and META-INF/eclipselink-orm.xml) won’t take effect unless they are listed in the persistence.xml. Uses can exclude the generated mapping file from persistence.xml by selecting the "Exclude from persistence.xml" checkbox. Is this a proper consideration?
  • What do we want to do when specified mapping file already exist? Do we want to just delete the old one and generate a new one? Do we want to support merge operation?
  • What if users want to convert Java sources with EclipseLink annotations to a generic mapping file? Should we give a warning message and convert all the metadata to the mapping file? Should we give a warning message and filter out the ElipseLink specific metadata?

Note:

  • Your feedback about the contents are very welcome.
  • It would be better if you could give your feedback with the format [name:feedback] to facilitate our communication, thanks!

References

User Interface Guidelines

Back to the top