Skip to main content
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
Back to the top