Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use / Coordi

[Thomas Hallgren <thomas@xxxxxxx>]

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
>