Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use / Coordination Ideas

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

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.


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>

"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
[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?


cross-project-issues-dev mailing list

Back to the top