Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use / Coordi

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

For our project, updating to the latest
Orbit build on a weekly basis is not warranted.  Also, the Orbit weekly
builds are frequently deleted which can result in build breakage trauma
:-( Our approach has always been to use the stable Orbit build that corresponds
to that milestone or release.   Or course if there are changes to
bundles that we consume we test them before the milestone.  

The Orbit team announces a stable build
at the beginning of our milestone week(+0).  For instance, David sent
a reminder a few days ago

http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg01931.html

How about another option
(d) All projects that rely on Orbit
jars agree to step up to the appropriate stable Orbit build each milestone.
  If a team cannot step up to this build, they should announce it
to the cross project list.


Kim

Nick Boldt/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

02/06/2008 02:32 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To	"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	[cross-project-issues-dev] Troubleshooting Orbit Bundle Use /        Coordination Ideas

Recently, there's been some discussion around building
products based on Ganymede.

One of the issues that has been raised is the problem that occurs when
a product uses more than one piece in Ganymede, and those pieces BOTH use
the same Orbit bundles -- but different versions. 

I'm not familiar with the details of why OSGi has problems when it encounters
two versions of, say, Batik or Xalan, but suffice to say bad things happen,
and the simplest workaround is to ensure that everyone that relies on Orbit
uses the same version of any given bundle.

There are a number of ways that have been suggested for how to best manage
this and avoid product breakages. These include:

a) every project that relies on Orbit jars agrees to step
up the the latest bleeding edge Orbit release every time a new one is available
(eg., weekly or biweekly).

b) every project that relies on Orbit jars, if they cannot step up to the
latest release in a timely manner, will post a note to this list stating
their deviation from rule (a), and when they might be able to adopt the
latest. This will allow other projects using the same bundles to coordinate
timing so they stay consistent.

c) every project that relies on Orbit jars will post a list of the jars
they consume on their Ganymede/Signoff page, so others will know what they
require and can coordinate with those projects to align themselves. Optionally,
this could also include the version of those bundles as a way of ensuring
consistency. Granted, this is more labour intensive than (b), and implies
regular updates instead of (hopefully) infrequent announcements, but it's
also more informative.

I put it to the group:

* Can everyone commit to (a) ? 

* In the event that you can't adhere to (a), would you
prefer (b) (report on deviation only) or (c) (report on status) as the
cross-project communication method? 

* Would (c) be useful (in addition to (b)) just for information's sake,
or is it overkill? And if you like (c), do you want to maintain version
#s in there too, or just bundle names?

Cheers,

Nick
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev