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.
Difference between revisions of "DaliMeetingMinutes20090714"
(→Open design issues (UI and model)) |
|||
| Line 7: | Line 7: | ||
==Agenda== | ==Agenda== | ||
| − | ===Open design issues (UI and model)=== | + | === Open design issues (UI and model) - whiteboard pictures to be added shortly<br> === |
| − | *UI and model for JPA 2.0 Id (Paul) | + | *UI and model for JPA 2.0 Id (Paul) |
| − | **Generic JPA is slightly different case than EL | + | **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 | |
| − | ***Is option 2 possible, lets consider further? | + | ****(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. |
| − | ***Day 2 Comments | + | ****Can @Id and @Basic coexist? |
| − | ****(one option)Make a model that makes sense (where Id is not a first class mapping), then | + | ****3 Options defined, see picture of white board, pros and cons with each |
| − | ****Can @Id and @Basic coexist? | + | ***Day 3 Comments |
| − | ****3 Options defined, see picture of white board, pros and cons with each | + | ****Reviewed options, best course of action to do some pair programming to tackle additional investigation |
| − | ***Day 3 Comments | + | ****First take a look at Option B, then pursue Option C if B turns out to be a dead end |
| − | ****Reviewed options, best course of action to do some pair programming to tackle additional investigation | + | *JPA 2.0 meta-model generation (Shaun) |
| − | ****First take a look at Option B, then pursue Option C if B turns out to be a dead end | + | **Probably want incremental generation (on commits) |
| − | *JPA 2.0 meta-model generation (Shaun) | + | **Talk to Michael O'Brian and Peter about serialization (set up meeting, incremental generation) |
| − | **Probably want incremental generation (on commits) | + | **What happens when the A processor regens, does it clean up<br> |
| − | **Talk to Michael O'Brian and Peter about serialization (set up meeting, incremental generation) | + | **We could tie into refactoring and update queries to point to new metamodel content |
| − | **What happens when the A processor regens, does it clean up | + | **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) | |
| − | **We could tie into refactoring and update queries to point to new metamodel content | + | *Legacy Platform support (Neil) |
| − | ** | + | **Should we support EclipseLink 1.x in Dali 3.0? Yes - keep everything for now |
| − | **Use EL to generate the source code (send an email to Peter) | + | *Platform version requirements (Paul) |
| − | *Legacy Platform support (Neil) | + | **Too much to do in 3.0, will need to wait to work on this as it becomes more necessary |
| − | **Should we support EclipseLink 1.x in Dali 3.0? | + | **Platform UI selection (Neil) |
| − | *Platform version requirements (Paul) | + | ***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. |
| − | **Too much to do in 3.0, will need to wait to work on this as it becomes more necessary | + | *Code Topics |
| − | **Platform UI selection (Neil) | + | **Conversion to Iterables (Brian) |
| − | ***New suggestion - create " | + | ***going to start with db plugin and see if this is worth pursuing further |
| − | *Code Topics | + | ***Lots of possible churn to provisional API. Need to determine if this is worth the churn |
| − | **Conversion to Iterables (Brian) | + | **Model events/listeners (Brian) |
| − | ***going to start with db plugin and see if this is worth pursuing further | + | ***Changes are good but there will be some adopter breakage |
| − | ***Lots of possible churn to provisional API. | + | **FindBugs(Brian) |
| − | **Model events/listeners (Brian) | + | ***Brian tried this out on Utility and had decent results (not much found, but some useful feedback) |
| − | ***Changes are good but there will be some adopter breakage | + | ***We will plan on using this the larger codebase during the course of 3.0 development <br> |
| − | **FindBugs(Brian) | + | **Performance testing<br> |
| − | ***Brian tried this out on Utility and had decent results (not much found, but some useful feedback) | + | **"2.0" naming and package names for various platforms (Karen) |
| − | + | ***need to define a pattern for all of this | |
| − | ***We will plan on using this the larger codebase during the course of 3.0 development | + | ***New metadata introduced for JPA 2.0 should get the 2_0 label in the class |
| − | **"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: | ***See picture below: | ||
Revision as of 17:23, 17 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) - whiteboard pictures to be added shortly
- 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