Jump to: navigation, search

Difference between revisions of "Orbit Minutes 070403"

(Modification of 3rd party bundles)
(Modification of 3rd party bundles)
 
Line 69: Line 69:
 
* Can we ignore certain bundles from packing in our process?
 
* Can we ignore certain bundles from packing in our process?
 
* Yes, 2 ways
 
* Yes, 2 ways
## Specified in an <code>eclipse.inf</code> in the bundle - but if we add this file then we are modifying the bundle.
+
# Specified in an <code>eclipse.inf</code> in the bundle - but if we add this file then we are modifying the bundle.
## Specifying a file as input to the build - but what happens when people want to run the Site Optimizer application on an entire update site? this file isn't necessarily available as input
+
# Specifying a file as input to the build - but what happens when people want to run the Site Optimizer application on an entire update site? this file isn't necessarily available as input
  
 
====Milestone week====
 
====Milestone week====

Latest revision as of 11:38, 3 April 2007

Attendees

  • Martin Oberhuber
  • David Williams
  • Tom Watson
  • Hubert Leung
  • Jeff McAffer
  • Pascal Rapicault
  • Simon Kaegi
  • Kim Moir
  • DJ Houghton

Discussion

Review action items from last call

IP Log info

A draft of an IP log document was reviewed by Jeff and Pascal and will be sent to the dev list for comments. The intent is for the document to live in the HEAD stream for each project and contain the appropriate IP info for all streams.

  • [Orbit IP Log] wiki page created.
  • People have been adding comments to page.
  • Action: DJ to start working on page generation from log files
  • Action: People to comment on wiki as to what they'd like to see on the generated pages

Orbit Map Files

To remove ambiguity created from combining map files from products with the ones produced by Orbit, we would like to ensure that the Orbit-produced map files always have a version for each map file entry. Is this possible?

  • Yes. Done.

Update features and map files

David to update the Orbit build process and try multi-versions in the map files. If everything works out he will combine the map and feature files. Note: Does this mean we are down to 1 feature.xml and 1 map file now?

  • Yes. Done. We now only have one map file and one feature file. Yeah!!

Xerces

There are some open issues with the Xerces bundle around splitting the API bundle into mutliple JARs.

  • Would like to split the org.w3c.dom bundle into 3 bundles.
  • Legal-type issues stand in the way. The versions of things included in Xerces are not always the exact versions as spec'd, there are minor changes.
  • We need to determine what these changes are.
  • Can we just bundle the spec'd versions instead?
  • Not sure if we can get this work completed for 3.3.
  • Contingency plan is to move content to a new bundle (that doesn't conflict in name) and that will be better for us when we actually do the split.
  • Action: David to send note to the mailing list describing this action.

Other discussion topics

Ant

Originally in Orbit we created a bundle called org.apache.tools.ant because it is the Orbit naming convention to use the dominant package name as the bundle name. We have determined that there are just too many people using Ant in scripts and other ways that we did not anticipate. It is recommended that we grandfather Ant and leave the org.apache.ant bundle name.

  • [Message] sent to the Orbit mailing list describing the problem.
  • People voted on the mailing list (no -1's)
  • No objections on the call.
  • Action: DJ to rename bundle to be org.apache.ant.

Modification of 3rd party bundles

How should we handle modifications to our 3rd party bundles. For example use-cases see: Chkpii errors, Should bundles be exploded or manifest edited, and Should we not condition prebuilt bundles?

  • Optimally we would like the producers of the 3rd party bundles to make the changes
  • Sometimes they don't want to change them or are too slow
  • If we tweak a bundle, then it needs to be expanded
  • We should ask the originator first, and then expand and tweak the bundle second if they can't do it.
  • We should NOT make code changes.
  • Only consider changes to manifests and properties files.
  • What about about.html files?
  • If a bundle comes to us with all the right legal info but it isn't called that, do we really need to create one?
  • Packing 3rd party bundles is another interesting problem.
  • There could exist problems in the packing algorithm and we if we produce the same bundle version as the originator, we won't know which is which and why it doesn't work.
  • Hard to track down these problems - bugs could be entered against Eclipse and then against the originator and bounce back and forth.
  • Its hard for us to ask people to add packing to their build process.
  • Can we ignore certain bundles from packing in our process?
  • Yes, 2 ways
  1. Specified in an eclipse.inf in the bundle - but if we add this file then we are modifying the bundle.
  2. Specifying a file as input to the build - but what happens when people want to run the Site Optimizer application on an entire update site? this file isn't necessarily available as input

Milestone week

Last milestone we promoted a stable build on Friday but this doesn't leave much time for the Platform team to run test builds with the new contribution to ensure things run smoothly.

  • If we can promote the build earlier in the week, then the build teams will be happy.
  • Action: We will promote builds on the Wednesday of milestone week

Next Meeting