Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/p2/Meetings/20081208"
| Line 36: | Line 36: | ||
*** Launcher branding and product publishing remains to be done | *** Launcher branding and product publishing remains to be done | ||
** Repository association work | ** Repository association work | ||
| − | *** Some work done in M4 already ([http://bugs.eclipse.org/234213 bug 234213) | + | *** Some work done in M4 already ([http://bugs.eclipse.org/234213 bug 234213]) |
*** Remaining question is whether to scope updates to a subset of available repositories | *** Remaining question is whether to scope updates to a subset of available repositories | ||
* Testing | * Testing | ||
** Tuesday is a test pass. Pascal covering Mac. John covering Vista. DJ covering Linux. Everyone welcome to help out with testing effort | ** Tuesday is a test pass. Pascal covering Mac. John covering Vista. DJ covering Linux. Everyone welcome to help out with testing effort | ||
** Thursday is test authoring day to focus on filling in coverage in our automated test suites | ** Thursday is test authoring day to focus on filling in coverage in our automated test suites | ||
| + | * Support for discovering different repository types | ||
| + | ** Need a mechanism to set order of repository type lookup | ||
| + | ** Current system only works well if there is only one type of repository at a given location | ||
| + | ** There is a current bug where a local repository containing a plugins directory can be interpreted as an extension location repository | ||
| + | * New collector work | ||
| + | ** SimplePlanner#gatherAvailableInstallableUnits currently takes all IUs in the world and stores them in an array. This is not scalable for large remote or database-backed repositories | ||
| + | ** Collector has a dual role: it holds the result of a query, but can also be subclassed for doing post-processing on the result of the query, short-circuiting the query, etc | ||
| + | ** p2 UI code has the more interesting use cases for queries/collectors - wrapping query results in UI model, etc | ||
| + | * Custom implementations of metadata objects | ||
| + | ** Want to use interfaces rather than classes for metadata API to allow for alternate implementations | ||
| + | ** Interfaces would still be specified as not to be implemented by clients | ||
Revision as of 17:19, 8 December 2008
Agenda
- Plan / M4 wrap up
- Testing
- Support for what "type" of repository will be loaded bug# 222251
- New Collector 256355 256411
- Interfaces for metadata types 256359
Attendees
- Andrew Cattle
- Andrew Niefer
- Curtis Windatt
- Dave Stevenson
- DJ Houghton
- Doug Schaefer
- Henrik Lindberg
- Ian Bull
- John Arthorne
- Pascal Rapicault
- Scott Lewis
- Simon Kaegi
- Susan McCourt
- Tom Watson
Minutes
- Plan review
- Dependency on update manager:
- Need to do investigation to provide replacement concepts, but don't plan to remove UM in 3.5.
- People can already run without UM if desired
- Metadata authoring workflow
- Some work has been done, but need to map out the vision describing how metadata goes from development time authoring, through build into deployed systems
- Install handler replacement
- Work has been moved to M5
- Complete integration of publisher with build
- Andrew N will write up description of remaining work
- Launcher branding and product publishing remains to be done
- Repository association work
- Some work done in M4 already (bug 234213)
- Remaining question is whether to scope updates to a subset of available repositories
- Dependency on update manager:
- Testing
- Tuesday is a test pass. Pascal covering Mac. John covering Vista. DJ covering Linux. Everyone welcome to help out with testing effort
- Thursday is test authoring day to focus on filling in coverage in our automated test suites
- Support for discovering different repository types
- Need a mechanism to set order of repository type lookup
- Current system only works well if there is only one type of repository at a given location
- There is a current bug where a local repository containing a plugins directory can be interpreted as an extension location repository
- New collector work
- SimplePlanner#gatherAvailableInstallableUnits currently takes all IUs in the world and stores them in an array. This is not scalable for large remote or database-backed repositories
- Collector has a dual role: it holds the result of a query, but can also be subclassed for doing post-processing on the result of the query, short-circuiting the query, etc
- p2 UI code has the more interesting use cases for queries/collectors - wrapping query results in UI model, etc
- Custom implementations of metadata objects
- Want to use interfaces rather than classes for metadata API to allow for alternate implementations
- Interfaces would still be specified as not to be implemented by clients