- Jeff McAffer
- Bjorn Freeman-Benson
- Christian Damus
- John Graham
- DJ Houghton
- Hubert Leung
- Pascal Rapicault
- Scott Lewis
- Simon Kaegi
- Martin Oberhuber
- David Williams
- Review action items from last call
- Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed. Bug 163746
Pascal confirmed that existing bundles are not downloaded again
- Simon to start a wiki page on how to manage source for Orbit bundles.
No progress on wiki. Simon has added source for many bundles in the repo. Looking to make some progress on the wiki today. Simon will also propose a template for the about files so that new projects have a hope of getting it right.
- David and Bjorn to start setting up the build Bug 163745
Some progress as far as design. Looking to have the real build setup running by Jan 1.
Action: David to setup a basic build for use in the mean time
- Jeff to confirm the legal requirements in this area
Jeff reviewed with Adrian and confirmed that there are no particular issues. The Eclipse project already ships features that consolidate several third party libs under a variety of licenses. Simon will produce a template for the about files.
- Bundle naming The [Bundle Naming] conventions call for bundles to be named after the dominant package in a library. This works reasonably well but there are "legacy" cases such as Ant and JUnit that work less well. We need to agree on an approach for naming these bundles.
- Lots of discussion
- General reconfirmation of using the dominant package name approach
- In cases where the dominiant package is "malformed" (e.g., Junit uses just "junit") we will, on a case by case basis, create a well-formed bundle symbolic name that is as close as possible to the originator's package naming.
- For existing bundles whose names do not follow these conventions (e.g., Ant, JUnit 4) we discussed whether we should go for consistency or leave well enough alone. The consensus was that all bundles in Orbit should follow the conventions and where that requires a change in the name of an existing bundle (e.g., org.junit4 => org.junit version 4) we can provide a compatibility wrapper bundle that has the old name and requires and reexports the new bundle.
Action: DJ to test the wrappering and see if there are any issues.
Action: Jeff to work with the PDE team to ensure that having multiple versions of the same bundle will work smoothly.
- Bundle registry
- There was some discussion around the need to expose which versions of which libraries are currently in Orbit. This is needed both for people to understand what is being worked on but also what is available for download.
- Agreed that each project should have a file in the HEAD branch that notes what branches there are.
- Each branch should then also have a readme.xml (or some such) to hold information such as version number, status, license, etc
- We can then create a server side tool that runs over the projects and gets all the files from the various branches and generates a table.
- The downloads page will end up having a table of available (built) versions
Action: Jeff to setup another call in three weeks.
Open Action Items
- Simon to creaate a wiki page on how to manage source for Orbit bundles. * David and Bjorn to start setting up the build
- Jeff to work with the PDE team to ensure that having multiple versions of the same bundle will work smoothly.
- Jeff to setup another call in three weeks.
- DJ to test the wrappering - created Bug 165356
- David to setup a basic build for use in the mean time