[
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
|
+1 for this change.
wenfeng
-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of
Christian Damus
Sent: Friday, February 08, 2008 4:38 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use
/Coordination Ideas
Looks like everybody's agreed, then.
I have committed and released https://bugs.eclipse.org/214410 to
implement
the work-around. There is a movement afoot to produce another Orbit
I-build, which would include this fix. That should give consuming
projects
like BIRT and GMF some opportunity to test it.
cW
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 09:51
Subject
PM Re: [cross-project-issues-dev]
Troubleshooting Orbit Bundle Use
/
Coordination Ideas
Please respond to
Cross project
issues
<cross-project-is
sues-dev@eclipse.
org>
Right. It seems like we might be onto a fix for this problem at the
Equinox level. Tom has been talking in the OSGi world and we may be able
to issue an errata to the spec and then implement something that would
allow Import-Package and Require-Bundle to play nicely together. My
guess is that that would address the problem here. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217724
In the meantime of course, we need to do something. I'd suggest we do
the least disruptive, most focussed workaround we can for near-term/M5
and see how the above bug goes after M5. Make sense?
Jeff
Christian Damus wrote:
> 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.h
tml
>
>> 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
>
>
> _______________________________________________
> 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
