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

Hey Christian, thanks for updating the bundle. Is it correct to say that the immediate problem is resolved? While Nick and Kim's suggestions are functionally expedient and we may have to do them it would be better to figure out a solution to the basic bug (as you noted below). So I'm hoping that your change buys some time to work on it.


Christian Damus wrote:
Hi, David,

The latest Orbit S-build updated the Batik Transcoder bundle so that it no
longer imports any exported packages.  However, this does not resolve the
problems caused by bundle duplication, which are still being investigated



Christian W. Damus
Component Lead, Eclipse OCL and EMF MQ/MT/VF
IBM Rational Sofware

David M Williams <david_williams@u> To Sent by: Cross project issues cross-project-iss <cross-project-issues-dev@eclipse.o ues-dev-bounces@e rg> cc Subject 02/07/2008 01:42 Re: [cross-project-issues-dev] AM Troubleshooting Orbit Bundle Use / Coordination Ideas Please respond to Cross project issues <cross-project-is sues-dev@eclipse. org>

I agree with Kim ... option 'd'.  I think we can only expect
synchronization at milestones .... and, that's the only predictable build
from Orbit, since we make and promote those "on demand", since we often go
for weeks with no or few changes.

Naturally, if there are some projects that find that some bundles are
especially sensitive to coordinate, then those projects can and should
coordinate well, but I think in the vast majority of bundles for the vast
majority of projects, there's no real impact if qualifiers differ a little
week to week.  The worst offenders, I think, are those bundles that both
import and export the same package (see bug 217724 for some possible future
relief). To my knowledge, org.apache.batik.transcoder is the only one that
does ... though, I'm sure there are others.

From: Kim Moir <Kim_Moir@xxxxxxxxxx> To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> Date: 02/06/2008 03:37 PM Subjec Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use / t: 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-boun ces@xxxxxxxxxxx To "Cross project issues" <cross-project-issues-dev@xxxxxxxxxx 02/06/2008 02:32 PM g> cc Please respond to Subject Cross project issues [cross-project-issues-dev] <cross-project-issues-dev@ec Troubleshooting Orbit Bundle Use /> Coordination Ideas

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

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
cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top