Skip to main content
Jump to: navigation, search


Revision as of 13:23, 4 August 2009 by (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Dali 3.0 Design Meetings

July 13-14th, 2009

Attendees: Shaun, Neil, Karen, Brian, Paul, Tran


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
  • 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:

Dali Whiteboard Refactoring 3.0.JPG

Other Topics

  • XML Translator issues
    • Need to escalate these issues and determine if support is going to be sufficient moving forward

Back to the top