Equinox/p2/Meetings/20090504

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