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"
m (→Dali 3.0 Design Meetings) |
|||
(13 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
July 13-14th, 2009 | July 13-14th, 2009 | ||
− | Attendees: | + | Attendees: Shaun, Neil, Karen, Brian, Paul, Tran |
==Agenda== | ==Agenda== | ||
− | ===Open design (UI and model) | + | === Open design issues (UI and model) === |
− | *UI for JPA 2.0 Id (Paul) | + | *UI and model for JPA 2.0 Id (Paul) |
− | *JPA 2.0 meta-model generation (Shaun) | + | **Generic JPA is slightly different case than EL |
− | ** | + | ***Is option 2 possible, lets consider further? If not, what are the possible solutions, Option 3 - Lobby spec committee for @DerivedId. |
− | * | + | ***Day 2 Comments |
− | *Legacy Platform support (Neil) | + | ****(one option)Make a model that makes sense (where Id is not a first class mapping), then customize 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. |
− | **Should we support EclipseLink 1.x in Dali 3.0? | + | ****Can @Id and @Basic coexist? |
− | *Platform version requirements (Paul) | + | ****3 Options defined, see picture of white board, pros and cons with each |
− | **Platform UI selection (Neil) | + | ***Day 3 Comments |
+ | ****Reviewed options, best course of action to do some pair programming to tackle additional investigation | ||
+ | ****First take a look at Option B, then pursue Option C if B turns out to be a dead end | ||
+ | *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<br> | ||
+ | **We could tie into refactoring and update queries to point to new metamodel content | ||
+ | **General 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) | ||
+ | **Too much to do in 3.0, will need to wait to work on this as it becomes more necessary | ||
+ | **Platform UI selection (Neil) | ||
+ | ***New suggestion - create "<unselected>" option as the default default. This forces the user to make a selection the first time, ensuring that they make an appropriate selection, and after that, this chosen platform will remain default. This solves all of the issues associated with this bug. | ||
+ | *Code Topics | ||
+ | **Conversion to Iterables (Brian) | ||
+ | ***going to start with db plugin and see if this is worth pursuing further | ||
+ | ***Lots of possible churn to provisional API. Need to determine if this is worth the churn | ||
+ | **Model events/listeners (Brian) | ||
+ | ***Changes are good but there will be some adopter breakage | ||
+ | **FindBugs(Brian) | ||
+ | ***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 <br> | ||
+ | **Performance testing<br> | ||
+ | **"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: | ||
+ | [[Image:Dali_Whiteboard_Refactoring_3.0.JPG]] | ||
===Other Topics=== | ===Other Topics=== |
Latest revision as of 13:23, 4 August 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
- Is option 2 possible, lets consider further? If not, what are the possible solutions, Option 3 - Lobby spec committee for @DerivedId.
- Day 2 Comments
- (one option)Make a model that makes sense (where Id is not a first class mapping), then customize 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
- Day 3 Comments
- Reviewed options, best course of action to do some pair programming to tackle additional investigation
- First take a look at Option B, then pursue Option C if B turns out to be a dead end
- 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
- General 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)
- Too much to do in 3.0, will need to wait to work on this as it becomes more necessary
- Platform UI selection (Neil)
- New suggestion - create "<unselected>" option as the default default. This forces the user to make a selection the first time, ensuring that they make an appropriate selection, and after that, this chosen platform will remain default. This solves all of the issues associated with this bug.
- Code Topics
- Conversion to Iterables (Brian)
- going to start with db plugin and see if this is worth pursuing further
- Lots of possible churn to provisional API. Need to determine if this is worth the churn
- Model events/listeners (Brian)
- Changes are good but there will be some adopter breakage
- FindBugs(Brian)
- 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
- Performance testing
- "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:
- Conversion to Iterables (Brian)
Other Topics
- XML Translator issues
- Need to escalate these issues and determine if support is going to be sufficient moving forward