How should we handle modifications to our 3rd party bundles. For an example of a use-case see:

+

How should we handle modifications to our 3rd party bundles. For example use-cases see: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=177330 Chkpii errors], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=180354 Should bundles be exploded or manifest edited], and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=178723 Should we not condition prebuilt bundles?]

−

+

* Optimally we would like the producers of the 3rd party bundles to make the changes

−

Chkpii errors - https://bugs.eclipse.org/bugs/show_bug.cgi?id=177330

+

* Sometimes they don't want to change them or are too slow

−

+

* If we tweak a bundle, then it needs to be expanded

−

Should bundles be exploded or manifest edited - https://bugs.eclipse.org/bugs/show_bug.cgi?id=180354

+

* We should ask the originator first, and then expand and tweak the bundle second if they can't do it.

−

+

* We should <strong>NOT</strong> make code changes.

−

Should we not condition prebuilt bundles? - https://bugs.eclipse.org/bugs/show_bug.cgi?id=178723

+

* 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

+

# 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

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.