Hi Rajini, I think your summary on the wiki is great. I have a couple of comments:
1. I believe SpringSource try to create sensible version ranges based on the versioning governance of the project, such as that of Apache [1]. I have no doubt this takes quite a bit of effort and there are a number of examples which do not follow guidelines, but it seems like a sensible place to start. At least this approach is not arbitrary and therefore, IMO, stands a chance of working in most situations. Arbitrary schemes will be difficult to explain and defend when issues arise. I dislike the idea of narrow or broad ranges for the reasons you state. 2. You asked if we should be able to work with bundles from other projects (e.g. ServiceMix, SpringSource Application Platform). I wonder if we're able to learn from these projects to seed our versioning. The SpringSource repository, for example, seems to allow this, although I'm no legal expert [2]. Regards, Graham. [1] http://commons.apache.org/releases/versioning.html [2] http://www.springsource.com/repository/app/faq;jsessionid=3F9467729AC282FE4E08199FDCE40863#q6 2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>: > Following on from the discussion on OSGi-enabling third party libraries ( > http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the > options for versioning Tuscany bundles and 3rd party libraries distributed > with Tuscany and the implications of choosing these options. I have put > together some notes on the wiki ( > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning) > > There were two outstanding questions from Simon Nash in the previous > discussion which I will summarize here to ensure that they are not lost in > this discussion. > > 1. Why can't we generate import constraints which will suit all > applications? > 2. *I'm concerned by the assumption here that Tuscany's versions of 3rd > party bundles will be used both by Tuscany and by applications. An > application may be using other software as well as Tuscany, and this other > software may include its own versions of bundles for javax.servlet or jaxb. > If Tuscany requires its versions of these bundles to be used, and the other > software requires its versions to be used, this requires the application > developer to understand how to resolve any conflicts.* > > The answer to 1) relates to how broad (or narrow) version ranges in imports > are. Broad ranges prevent isolation and reduce scope for side-by-side > execution, narrow ranges prevent class sharing and upgrading to newer > versions. There is more detail with examples on the wiki. > > Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show these > scenarios). I would personally like to follow OSGi best practice and enable > maximum sharing. There are some cases where we have no choice but to share > (eg. SDO). I don't believe we can eliminate conflicts altogether - but > following standard practice will make it less complicated for OSGi > developers to resolve conflicts. > > Thoughts? > > > Thank you... > > Regards, > > Rajini >
