[
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
|
Hi, Jeff,
It seems that my latest hypothesis in bug 214410 was correct: the class
loading problems in BIRT and GMF stem from a mix of Import-Package and
Require-Bundle dependencies: the former used within the Batik bundles and
the latter within BIRT and GMF, for their dependencies on Batik.
So, I have a patch that updates all of the Batik bundles to use
Require-Bundle for their inter-bundle dependencies, and this seems to cause
BIRT and GMF no issues at run-time, when multiple copies of Batik are
installed.
I'll be happy to commit these changes for the next Orbit build (and yet
another copy of Batik! :-) ) but I'm only concerned about this departure
from Orbit's mandate to stick with the OSGi-recommended Import-Package. Of
course, as an Eclipse project, we need to do what's best for Eclipse.
Cheers,
Christian
Christian W. Damus
Component Lead, Eclipse OCL and EMF MQ/MT/VF
IBM Rational Sofware
Jeff McAffer
<jeff@xxxxxxxxx>
Sent by: To
cross-project-iss Cross project issues
ues-dev-bounces@e <cross-project-issues-dev@eclipse.o
clipse.org rg>
cc
02/07/2008 08:44 Subject
AM Re: [cross-project-issues-dev]
Troubleshooting Orbit Bundle Use /
Coordination Ideas
Please respond to
Cross project
issues
<cross-project-is
sues-dev@eclipse.
org>
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.
Jeff
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
> here:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214410
>
> Cheers,
>
> Christian
>
>
>
>
> Christian W. Damus
> Component Lead, Eclipse OCL and EMF MQ/MT/VF
> IBM Rational Sofware
>
>
>
> David M Williams
> <david_williams@u
> s.ibm.com>
To
> Sent by: Cross project issues
> cross-project-iss
<cross-project-issues-dev@eclipse.o
> ues-dev-bounces@e rg>
> clipse.org
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
>
>
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-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 /
> lipse.org> 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
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
