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
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.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


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

Back to the top