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
