[
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
|
Buckminster can commit to (a). Personally, I think (c) is an overkill. I
would much rather condense the information to contain the exceptions
only, i.e. (b). For us, that would result in no work at all. Also,
although (c) would contain more information, I would consider (b) more
informative since the information as such would be much easier to digest.
Regards,
Thomas Hallgren
Nick Boldt wrote:
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