Orbit Minutes 070213
- Call convened at 1100 EST
- Call-in: 613.287.8000 or 866.362.7064, passcode 892048#
- Previous Meeting: Orbit Minutes 070130
- 1 Attendees
- 2 Discussion
- 2.1 Review action items from last call
- 2.2 Other discussion topics
- 3 Next Meeting
- David Williams
- Jeff McAffer
- Kim Moir
- Simon Kaegi
- Pascal Rapicault
- DJ Houghton
- Hubert Leung
- Christian Damus
Review action items from last call
GET URL Fetch Factory
Pascal and DJ to test GET fetch factory for inclusion into PDE/Build.
- Done. GET fetch factory implemented in PDE/Build and contributed to Eclipse 3.3 M5.
Producing an Orbit map file
Kim/Pascal to contact David re: having the Orbit build process produce a map file for consumers.
- In progress
- JAR is in bug report.
- Action: Pascal to add source to JAR.
- Where should this JAR live? (more discussion below)
Martin to send their TM IP Log info to mailing list
- But we still need to come up with a skeleton doc.
- We are getting close to the Eclipse SDK 3.3 release and people are becoming more interested and will want this information soon.
- Action: Pascal to work on doc. Jeff to review.
Multiple Plug-in Versions in Map file
Pascal to investigate PDE/Build allowing for multiple plug-in versions in the same map file.
- Done. Support in Eclipse 3.3 M5.
Orbit Stable Builds
David and Kim to write up a short doc on what is required for Orbit "stable" builds; Martin to review.
- Done. This is the document: Promotion, Release, and Retention Policies.
- Action: Kim to update document to say the milestone is the platform milestone - 1.
OBR Fetch Factory
Simon to give progress report on OBR fetch factory.
- Item deferred
Kim investigating if we should be signing our bundles.
- yes we should sign them
- otherwise others will have problems since some jars can be signed, others can't
- how do we skip JARs and then mark them so downward people know to skip them?
- need to make this as auto as possible
- there is a bug around re-signing JARs.
- Action: Kim to open bug report about re-signing JARs.
Platform to consume Orbit bundles
Platform to consume orbit bundles for M5. Note this requires promoting an Orbit build.
- In progress
- Eclipse 3.3 M5 contains some Equinox bundles from Orbit.
- Action: Kim is experimenting with other bundles.
Other discussion topics
Update Orbit Builder
There have been multiple fixes in PDE/Build to handle new fetch factories and multiple versions in map files. The Orbit builder needs to be updated to use the latest PDE/Build code.
- Action: Kim to tag HEAD and David to update builder
Update features and map files
Once the builder is updated, it will be able to handle building multiple versions of the same bundle. Therefore we should be able to simplify our build story so we only have to have one map file (in HEAD) and a single feature.
- Action: David to try multi-version and if everything works out he will combine the map and feature files.
Map File Generator
Pascal has created the code which will create a map file based on the output of the build and GET calls. Where should this code live?
- Action: Pascal to create and release code into org.eclipse.orbit.releng.tools project.
- do we need a naming convention? people will want to fetch this file. for now it will live in the top of each stable dir
- need to better document how to re-consume
- doc cleaning up your map files to remove refs to orbit bundles
- important to mention that it requires M5 base builder and the pde builder
- Action: Kim to document. Pascal to review.
Do we expect many more contributions to Orbit in the Eclipse SDK 3.3 timeframe?
- TPTP has a bunch of bundles in the pipeline with potential to be orbited.
Sign-off Process for Stable Builds
- contributors are consumers so if people are getting the wrong thing, then hopefully they will fix it
- for stable builds, announce to the mailing list and people can object
Modification of JARs
- commons.net provides and extension to eclipse.ant.core
- need to document this
- should be rare
- how to do contributions and extensions? should we try and document a best practice or is it decided on a case by case basis?