Jump to: navigation, search

EclipseLink/Build/Requirements

< EclipseLink‎ | Build
Revision as of 15:32, 5 January 2011 by Eric.gwin.oracle.com (Talk | contribs)

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

Past requirements used in designing the build (1.0+)

  • Need reproducable Build automation quickly
  • EclipseLink component builds need to be runnable on other non-eclipse IDEs (IntelliJ, JDev, etc)
  • EclipseLink component builds need to be able to execute from either the hierarchical (SVN) tree, or a flat directory structure (all components at the same level
  • Full build system needs to be under version control


Other requirements used in designing the build

  • Need to be able to specify java class compatibility regardless of compiler level. (ie. generate for 1.5 using a 1.6 compiler)


Requirements Inherited from Simultanious Release Participation

  • All published builds must be signed by the foundation (effectively Milestone and release builds)
  • Must provide 'features' for Eclipse installers
  • Must provide builds in P2 repository
  • Product/features/plugins must follow Eclipse versioning conventions (Major.Minor.Micro.qualifier)
  • Shared Dependencies must come from Orbit (same as rest of release)


Moving Forward (2.3.0+)

  • All Previous requirements except:
    • EclipseLink component builds need to be runnable on other non-eclipse IDEs (IntelliJ, JDev, etc)
    • EclipseLink component builds need to be able to execute from either the hierarchical (SVN) tree, or a flat directory structure (all components at the same level
  • EclipseLink needs to adopt a more dynamic dependency resolution mechanism
    • cannot continue to merge Orbit and other dependencies into repos
    • mechanism must maintain build reproducability
      • cannot rebuild a past release and get latest dependencies - must be SAME dependencies
  • EclipseLink needs to shift from the old JEE to OSGi centric organization
    • Builds should rely upon the manifest info for compile and runtime dependency info/versioning
    • Any given component should build only when the component code changes
    • Bundle version info should be updated per actual component build (split marketing and bundle versioning)
  • 'Features' should dynamically generate on a per build basis
  • Nightly should use same system, or at least not interfere at all with Eclipse/Dev builds
  • Notes:
    • All 'Simultanious release' Requirements apply
    • All/Some/None of 'Past Requirements' apply