Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/JPA 2.0/metamodel api"
(→Work Estimate) |
m (→JPA 2.0: MetaModel API) |
||
Line 2: | Line 2: | ||
= JPA 2.0: MetaModel API = | = JPA 2.0: MetaModel API = | ||
− | [[EclipseLink/Development/JPA_2.0 | JPA 2.0 Root]] | {{bug| | + | [[EclipseLink/Development/JPA_2.0 | JPA 2.0 Root]] | {{bug|266912}} |
{|{{BMTableStyle}} | {|{{BMTableStyle}} | ||
Line 11: | Line 11: | ||
|- | |- | ||
| March 3, 2009 || [[User:Gordon.yorke.oracle.com | gyorke]] || Initial feature template | | March 3, 2009 || [[User:Gordon.yorke.oracle.com | gyorke]] || Initial feature template | ||
+ | |- | ||
+ | |- | ||
+ | | March 3, 2009 || [[User:Michael.obrien.oracle.com | mobrien]] || Start analysis | ||
|- | |- | ||
|} | |} | ||
Line 31: | Line 34: | ||
* APT tooling/testing | * APT tooling/testing | ||
*: approx 10 days | *: approx 10 days | ||
+ | |||
+ | == Concepts == | ||
== Functional Requirements == | == Functional Requirements == | ||
Line 38: | Line 43: | ||
== Design == | == Design == | ||
+ | |||
+ | === Design Constraints === | ||
+ | |||
== Documentation == | == Documentation == | ||
+ | == Implementation == | ||
== Testing == | == Testing == | ||
== Open Issues == | == Open Issues == | ||
+ | |||
+ | This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements. | ||
+ | |||
+ | {|{{BMTableStyle}} | ||
+ | |-{{BMTHStyle}} | ||
+ | ! Issue # | ||
+ | ! Owner | ||
+ | ! Description / Notes | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | == Decisions == | ||
+ | |||
+ | This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important. | ||
+ | |||
+ | {|{{BMTableStyle}} | ||
+ | |-{{BMTHStyle}} | ||
+ | ! Issue # | ||
+ | ! Description / Notes | ||
+ | ! Decision | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | == Future Considerations == | ||
+ | |||
+ | During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system. |
Revision as of 16:03, 3 March 2009
JPA 2.0: MetaModel API
Date | Committer(s) | Description |
---|---|---|
March 3, 2009 | gyorke | Initial feature template |
March 3, 2009 | mobrien | Start analysis |
Summary
In JPA 2.0 the specification has defined standard APIs for representing the structure of a persistence unit model. This is referred to at the MetaModel APIs. There are two main aspects to providing this functionality. The first is the runtime model accessed from EntityManagerFactory.getMetaModel() and the second is the APT generated meta model classes. Our first goal is to provide functionality for runtime access.
For details see section 5.2 and 5.3 of Proposed Final Draft.
Work Estimate
- Investigate EclipseLink Metamodel
- approx 3 days
- Develop implementations of MetaModel or refactor current metamodel
- approx 10 days
- APT investigation and prototype
- approx 5 days
- APT tooling/testing
- approx 10 days
Concepts
Functional Requirements
- Support runtime Metamodel APIs
- Support APT generation of Canonical Metamodel classes
Design
Design Constraints
Documentation
Implementation
Testing
Open Issues
This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.
Issue # | Owner | Description / Notes |
---|---|---|
Decisions
This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.
Issue # | Description / Notes | Decision |
---|---|---|
Future Considerations
During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.