Jump to: navigation, search

Equinox/p2/Meetings/20090504

< Equinox‎ | p2‎ | Meetings

Attendees

  • Jeff McAffer
  • Simon Kaegi
  • Darin Wright
  • Curtis Windatt
  • Chris Aniszczyk
  • Doug Schaefer
  • Tom Watson
  • Scott Lewis
  • Susan McCourt
  • Igor Fedorenko
  • Henrik Lindberg
  • Ian Bull
  • Andrew Niefer
  • DJ Houghton
  • John Arthorne
  • Pascal Rapicault

Javadoc

  • we don't ship javadoc
  • our APIs are provisional
  • people want APIs to start hacking code
  • javadoc itself is mostly not written in the code
  • also includes errors
  • what does "publish" mean? part of the SDK? on our web site?
  • all platform javadoc is together in one bundle
  • if we publish it, it would be embarassing little but would be even more embarassing to be wrong
  • we don't need javadoc for everything to begin with
  • pascal to talk to Olivier about the javadoc builder and potential issues
  • plan is to publish partial javadoc - does "partial" mean per package? what is the granularity?
  • make sure the API says "provisional"
  • what about schema doc for extensions registry things? maybe action stuff but not repos, for instance. pascal to look at it

Eclipse RCs

  • It is RC1 and not open season
  • focused bug fixes
  • weigh benefit versus risk
  • don't fix things just for the sake of it
  • focus on the big things first

ECF Build Contribution

  • Scott co-ordinating with Henrik on error code issues
  • will have build contributions ready by Wed 8pm (EST) during RC phase
  • RC candidate build is on Thurs 8pm

Target Provisioning

  • Target platform provisioning. See Bug 272750
  • 3.4 you download repo, extract, and add those dirs to your target def
  • 3.5 you can add a repo as well
  • uses a profile, create a plan and then collect and install the IUs into the profile (note this is platform specific)
  • easier to share with team, reusable, uses bundle pool
  • can still use delta pack in same way as you did in 3.4
  • people produce p2 repos as part of their build, but how are they intended to be consumed?
  • repos are incomplete (RT repo contains only RT stuff, don't contain JRE, etc)
  • original intention was for providing the repos to pde/build as repos to build against
  • saved having to regenerate metadata
  • we used the repo2runnable to put things in "compile against" form
  • prob: the repositories are merged into the same list as you have in your install, they aren't confined to the target
  • prob: grabbing fragments, optional pieces, and platform specific pieces
  • galileo builder runs the planner once per platform config and then collects everything and then goes and grabs everything
  • need to weigh and manage user expectations
  • when they add a repo to add EMF, should they be expected to add a repo for the SDK to satisfy requirements?
  • Help is another example... is not runnable on its own, needs other stuff
  • major issues are
    • how to consume downloadable zips
    • multi-platform
    • inclusion of all dependencies or not