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
Remaining question is whether to scope updates to a subset of available repositories
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
Version numbers
Awaiting further review of version patch. Please read the proposal and give your feedback.