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 "DaliMeetingMinutes20090714"
(→Open design issues (UI and model)) |
(→Open design issues (UI and model)) |
||
Line 32: | Line 32: | ||
**Conversion to Iterables (Brian) | **Conversion to Iterables (Brian) | ||
**Model events/listeners (Brian) | **Model events/listeners (Brian) | ||
+ | ***Changes are good but there will be some adopter breakage | ||
**FindBugs(Brian) | **FindBugs(Brian) | ||
+ | **Performance testing | ||
+ | ***Brian tried this out on Utility and had decent results (not much found, but some useful feedback) | ||
+ | ***We will plan on using this the larger codebase during the course of 3.0 development | ||
**"2.0" naming and package names for various platforms (Karen) | **"2.0" naming and package names for various platforms (Karen) | ||
***need to define a pattern for all of this | ***need to define a pattern for all of this |
Revision as of 17:36, 14 July 2009
Contents
Dali 3.0 Design Meetings
July 13-14th, 2009
Attendees: Shaun, Neil, Karen, Brian, Paul, Tran
Agenda
Open design issues (UI and model)
- UI and model for JPA 2.0 Id (Paul)
- Generic JPA is slightly different case than EL
- Generic - source only case, private in foo; - default to Basic mapping in our UI: M-1 default is error with Id
- EclipseLink - default 1:1 makes interpretation difficult
- Is option 2 possible, lets consider further? If not, what are the possible solutions, Option 3 - Lobby spec committee for Derived Id.
- Day 2 Comments
- (one option)Make a model that makes sense (where Id is not a first class mapping), then hack the UI as necessary to "simplify" UI. We could probably add an Id mapping into the map as list in a hard-coded, fixed list position (of 2), and then enable/disable this menu item based on the attribute type. The Id selection would only be enabled for primitives.
- Can @Id and @Basic coexist?
- 3 Options defined, see picture of white board, pros and cons with each
- Generic JPA is slightly different case than EL
- JPA 2.0 meta-model generation (Shaun)
- Probably want incremental generation (on commits)
- Talk to Michael O'Brian and Peter about serialization (set up meeting, incremental generation)
- What happens when the A processor regens, does it clean up.
- We could tie into refactoring and update queries to point to new metamodel content
- Generally annotation processor created, but might be advantage to doing this with the Dali model
- Use EL to generate the source code (send an email to Peter)
- Legacy Platform support (Neil)
- Should we support EclipseLink 1.x in Dali 3.0? Yes - keep everything for now
- Platform version requirements (Paul)
- Platform UI selection (Neil)
- Code Topics
- Conversion to Iterables (Brian)
- Model events/listeners (Brian)
- Changes are good but there will be some adopter breakage
- FindBugs(Brian)
- Performance testing
- Brian tried this out on Utility and had decent results (not much found, but some useful feedback)
- We will plan on using this the larger codebase during the course of 3.0 development
- "2.0" naming and package names for various platforms (Karen)
- need to define a pattern for all of this
- New metadata introduced for JPA 2.0 should get the 2_0 label in the class
- See picture below:
Other Topics
- XML Translator issues
- Need to escalate these issues and determine if support is going to be sufficient moving forward